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Preface 


Purpose  of  this  Document 


This  document  is  the  final  report  documenting  the  AFRL  /  HEC  effort  entitled  Global  Air  Mobility 
Advanced  Technologies  (GAMAT)  in  its  'Phase  II'  period.  The  Phase  II  effort  was  undertaken  as  an 
extension  and  expansion  of  the  GAMAT  Phase  I  effort. 

This  final  report  provides  descriptions  of  the  phase  II  efforts: 

•  Work-Centered  Knowledge  Acquisition  and  Analysis  Approach 

•  Work-Centered  Analysis  and  Design  Concepts  to  Support  Air  Mobility  Command  (AMC)  ‘s  Tanker 
Airlift  Control  Center  (TACC)  Flight  Planning-related  Collaboration  Work 

•  Work-Centered  Analysis  and  Design  Concepts  to  Support  TACC  Flight  Planning  Work 

•  Work-Centered  Support  System  for  Global  Weather  Management  Spiral  2  Demonstration  Capability 
Research  and  Development 


Related  Documents 


•  WCSS-GWM  Operations  Manual  (For  Scott  Air  Force  Base),  12  December  2003. 

•  WCSS-GWM  Users  ’  Manual,  1 7  December  2003 . 

•  AFRL  (2003,  December).  The  Foreign  Clearance  Guide  (FCG)  Project:  Diplomatic  Clearance 
Solutions  for  the  Integrated  Flight  Management  System  -  An  AFRL  IFM  /  ATD  Component. 
PowerPoint  slide  used  as  SAB  poster,  December  2003. 

•  BBN  Technologies  (2003,  July).  Using  the  ACT  Tool  -  Users  Guide.  Application  manual  produced 
by  BBN  in  relation  to  DIP  software  development. 

•  Eggleston,  R.  G.  (2003)  “Work-Centered  Design:  A  Cognitive  Engineering  Approach  to  System 
Design”.  Proceedings  of  the  Human  Factors  and  Ergonomics  Society  47th  Annual  Meeting.  Santa 
Monica,  CA.  Human  Factors  and  Ergonomics  Society. 

•  Scott,  R.,  Roth,  E.  M.,  Deutsch,  S.  E.,  Malchiodi,  E.,  Kazmierczak,  T.,  Eggleston,  R.  and  Kuper,  S. 
R.,  Whitaker,  R.  (in  press)  “Work-Centered  Support  Systems:  A  Human-Centered  Approach  to 
Intelligent  System  Design”.  IEEE  Intelligent  Systems. 


iv 


•  SRA  International  (2002,  March).  Advanced  Computer  Flight  Plan  Operational  Requirements 
Document.  Report  prepared  for  GSA  and  AMC  under  FEDSIM  Project  Number  97084AFE-04,  29 
March  2002. 

•  White  Paper  on  the  Flight  Planning  System  Assessment,  anonymous  review  of  Advanced  Computer 
Flight  Planner  (ACFP)  and  recommendations  for  the  next-generation  ACFP  and  related  capabilities, 
AMC,  March  2001. 


Project  Background 


This  demonstration  capability  was  developed  under  the  Air  Force  Research  Laboratory  Human 
Effectiveness  Directorate’s  Global  Air  Mobility  Advanced  Technologies  (GAMAT)  Advanced 
Technology  Development  (ATD)  research  and  development  program.  The  goal  of  the  GAMAT  ATD 
was  to  further  the  development  of  a  new  type  of  user  interface  technology  called  Work-Centered 
Support  System  (WCSS)  technology.  The  U.S.  Air  Force’s  Air  Mobility  Command’s  command  and 
control  environment  was  used  as  the  domain  for  development,  testing  and  refinement  of  WCSS  theories 
and  technology  applications. 


WCSS  Technology 


Work-Centered  Support  System  (WCSS)  technology  is  a  new  cognitive-science-based  analysis  and 
design  methodology  for  developing  human-computer  interfaces  and  client  applications  that  enable  very 
high  user  productivity,  especially  in  dynamic  and  information  dense  environments.  The  WCSS 
technology  is  applicable  to  any  domain  and  leverages  cognitive  analyses  and  advanced  user  interface 
design  techniques  to  provide  ‘intuitive’  user  interfaces  and  client  applications  customized  based  on  the 
work  requirements.  The  analysis  and  design  approach  is  designed  to  support  rapid  user  adaptation  to 
both  routine  and  non-routine/unexpected  events.  This  is  accomplished  by  providing  relevant  context  and 
intuitive,  directly  manipulatable  affordances  for  action.  Both  form-based  and  automation-based  aiding  is 
used  to  provide  the  needed  information  to  support  rapid  and  adaptive  problem  solving  (in  the  WCSS- 
GWM,  intelligent  agents  are  used  as  automation  aids)  and  reduce  the  potential  for  ‘information 
overload’  and  associated  errors  and  decreases  in  work  efficiency.  The  scope  of  work  activities  analyzed 
and  potential  aiding  concepts  includes  support  for  decision  making,  product  production,  collaboration 
and  coordination,  as  well  as  individual  and  team  level  work  organization. 
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1.1  Knowledge  Acquisition  and  Analysis  Approach 


A  fundamental  aspect  of  the  work-centered  design  approach  is  an  analysis  and  modeling  of  the  work 
ecology >  to  uncover  the  elements  of  work  that  require  support.  The  process  starts  with  knowledge 
acquisition  (KA)  methods  such  as  ethnographic  field  observations  and  structured  interview  techniques  to 
uncover  the  characteristics  of  the  work  domain,  the  work  requirements,  the  sources  of  complexity  and 
cognitive  and  collaborative  demands  entailed.  Formal  methods  can  then  be  employed  to  represent  ihe 
results  of  the  analysis  (work  ecology  modeling).  These  include  work  domain  analysis  methods  that 
model  the  intrinsic  characteristics  of  the  work  to  be  achieved  as  well  as  methods  that  model  workflow 
dynamics  within  and  across  individuals  and  groups  required  to  achieve  work  goals. 

The  products  of  work  ecology  modeling  define  the  work-aiding  requirements  to  support  domain 
practitioners  in  performing  work  in  a  flexible  and  adaptable  manner,  given  the  dynamics  of  the  work 
context.  These  requirements  are  used  to  guide  work-aid  design  that  involves  development  and 
prototyping  of  work-aiding  concepts.  Work  aiding  may  take  the  form  of  representational  aiding  that  is 
provided  through  the  use  of  work  domain  visualizations  or  direct  aiding  provided  by  a  coordinated  set  of 
software  agents  that  interact  with  the  user  that  are  clearly  connected  to  or  are  embedded  in  the  work 
domain  visualizations  (Eggleston,  2003;  Scott,  et  al.,  in  press). 

The  knowledge  acquisition  effort  in  the  present  project  focused  on  current  flight-planning  practices  at 
the  U.S.  Air  Force  Air  Mobility  Command  (AMC)  at  Scott  Air  Force  Base,  and  opportunities  to  employ 
work-centered  support  system  concepts  to  improve  it.  The  location  of  the  operations  studies  were  in 
AMC’s  Tanker  Airlift  Control  Center  (TACC). 


KA  Collection 

KA  collection  activities  were  undertaken  with  the  overall  objective  of  modeling  the  ecology  of  the  work 
environment  that  is  currently  in  use  for  flight  planning.  Activities  consisted  of  interviews  and 
observations  whose  specific  objectives  were  to: 

•  Understand  the  ‘as-is’  process 

•  Understand  sources  of  task  complexity: 

-  In  both  routine  cases  as  well  as  non-routine  situations  that  are  important  to  support 

-  Examine  inherent  constraints  in  the  domain  that  complicate  performance 

•  Understand  cognitive  and  collaborative  processes  that  need  to  be  supported  (within  and  across 
organizational  boundaries) 

•  Define  work-centered  design  approaches  and  software  agent  technologies  to  enable  more  proactive 
response 
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Focus  of  observations  and  interviews  included: 

•  The  current  Flight  Planning  process  employed  by  the  flight  planning  shop 

•  The  interaction  between  the  flight  planning  process  and  the  DIP  Clearance  process 

•  How  the  flight  planning  process  fits  into  the  larger  mission-planning  process 

•  The  work  and  perspectives  of  other  important  contributors  to  the  flight  planning  process: 

-  Flight  Managers 

-  Execution  Cell  operations  (Formerly  East  and  West  Cell) 

-  XOCX  aerial  ports  cell 

A  second  aim  of  the  knowledge  acquisition  effort  was  to  obtain  feedback  on  preliminary  WCSS  design 
concepts  that  were  developed  as  part  of  this  program.  Story  boards  illustrating  proposed  WCSS  design 
concepts  were  presented  to  representatives  of  the  target  user  communities  to  elicit  their  feedback  as  an 
aid  to  prioritizing  the  design  ideas  and  further  refining  them. 

Collection  Methodology 

Analysts  undertook  five,  multi-day,  KA-survey  trips  to  AMC,  the  first  in  December  of  2002,  with 
additional  visits  in  the  following  March,  June,  September,  and  November  of  2003. 

During  the  KA  trips  analysts  undertook  interviews  with  the  following  groups  involved  in  flight  planning 
work: 

•  Flight  Planning  Shop 

•  “Customers”  of  Flight  Planning  product: 

-  DIP  Shop 

-  Mission  Planners 

-  Flight  Managers 

-  Execution  Cell 

•  AMC  staff  involved  in  shaping  future  of  the  TACC 


2 


KA  Analysis 

KA  analysis  consisted  of  an  effort  to  diagram  the  flight-planning  process,  to  understand  the  dynamics  of 
the  process,  and  sources  of  task  complexity  with  a  view  toward  developing  Work-centered  Support 
System  (WCSS)  concepts  for  improving  performance.  The  analysis  effort  generated  a  variety  of  aids  to 
facilitate  understanding  current  practices,  including  aids  to: 

•  Visualize  the  current  overall  flight  planning  process 

•  Visualize  the  TACC  staff  roles  involved  and  the  way  they  interact. 

•  Identify  sources  of  actionable  issues  (e.g.,  complexities,  delays) 

Figure  1  shows  an  example  of  one  of  the  aids  generated.  Others  are  provided  in  Appendix  B. 


Figure  1 :  Mapping  among  Interacting  Factors  Affecting  Flight  Planning 
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Design  Recommendations  and  User  Feedback  Session 

After  iterative  KA  sessions  and  analysis,  basic  findings  and  preliminary  recommendations  were 
presented  to  multiple  AMC  personnel  and  feedback  was  solicited  relative  to  those  findings  and 
recommendations  during  a  session  on  12  Nov  03.  This  was  in  addition  to  the  initial  individual  KA 
sessions  and  informal  follow-up.  During  the  12  Nov  03  session,  feedback  was  solicited  regarding: 

•  The  usefulness  of  the  proposed  capabilities: 

-  Would  you  use  it? 

-  In  what  situations? 

-  What  other  groups  (positions)  might  find  this  useful? 

•  Potential  additional  enhancements  that  would  be  useful  that  should  be  analyzed  further 
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1.2  TACC  Flight  Planning-related  Collaborative  Work  and  Flight  Planning  Work 

Analysis  and  Design  Effort  Overview 

During  the  first  phase,  the  Global  Air  Mobility  Advanced  Technologies  (GAMAT)  research  and 
development  program  investigated  the  efficacy  of  applying  the  emerging  Work-Centered  Support 
System  (WCSS)  methodology  and  resulting  client  applications  to  support  a  select  portion  of  the  Air 
Mobility  Command  (AMC)  work  domain.  The  effort  researched,  developed  and  demonstrated 
performance-enhancing  information  technologies  (IT)  in  support  of  weather  (WX)  impact  mitigation  on 
AMC  managed  airlift  and  tanker  aircraft  missions,  called  the  Work-Centered  Support  System  for  Global 
Weather  Management  (WCSS-GWM).1  The  results  of  this  work  were  briefed  to  AMC  customers  and 
documented  in  a  final  report.  Toward  the  end  of  the  GAMAT  Phase  I  effort  the  GAMAT  team  was 
directed  to  begin  consideration  of  applying  WCSS  principles  and  designs  to  the  entirety  of  the  AMC  / 
TACC  environment. 

In  Phase  II  of  the  GAMAT  effort,  we  continued  our  Phase  I  work  with  regard  to  two  topics  as  follows: 

•  The  WCSS-GWM  tool  from  Phase  I  was  carried  over  for  limited  refinement,  test  deployment,  and 
evaluation. 

•  The  Phase  I  assignment  to  develop  WCSS  concepts  addressing  the  whole  of  AMC  /  TACC 
collaborative  work  processes  was  carried  over  as  a  focus  for  ongoing  Phase  II  consideration. 

Beyond  these  'carry-over'  themes,  our  Phase  II  work  was  directed  toward  flight  planning  as  a  central 
focus.  In  previous  projects  AFRL  teams  had  studied  channel  mission  planning  (Human  Interaction  with 
Software  Agents  (HISA)  project),  integrated  flight  management  (IFM  project),  and  TACC  weather 
operations  (GAMAT  Phase  I).  This  left  the  'flight  planning  shop'  as  the  largest  mission  work  process 
chain  yet  to  be  examined.  In  Phase  II  our  knowledge  acquisition  (KA),  analysis,  and  design  efforts  were 
therefore  concentrated  primarily  on  the  flight  planners  (FP's). 

In  addition  to  these  foci  for  GAMAT  Phase  II  study,  some  other  TACC  units  and  functions  were 
addressed.  Owing  to  the  importance  of  the  flight  planners'  recurrent  interactions  with  mission  planners 
(MP's)  and  with  the  diplomatic  clearances  (DIP's)  shop,  we  accorded  secondary  attention  to  those  units. 
In  accordance  with  the  emerging  importance  of  the  new  'execution  cell'  or  'execution  floor’  facility 
within  TACC,  we  also  gave  attention  to  that  organizational  unit. 


The  Phase  II  Effort  in  Terms  of  Subject  Work(er)  Granularity 

The  specification  of  an  overall  WCSS  concept  within  the  GAMAT  Phase  I  project  context  was 
described  with  regard  to  three  distinguishable  levels  of  organizational  granularity: 


1  At  various  times,  the  WCSS-GWM  had  also  been  referred  to  as  'GAMAT',  'GAMAT  prototype',  and  'Weather  Management 
Tool  (WMT)'. 
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•  Individual  User.  This  level  of  granularity  pertains  to  consideration  of  a  single  worker  or  user.  In 
the  case  of  GAMAT  Phase  I,  this  was  the  granularity  at  which  the  WCSS-GWM  was  framed. 

•  Group  /  Cluster  of  Users:  In  the  case  of  GAMAT  Phase  I,  this  was  the  level  of  granularity  at  which 
we  addressed  (a)  the  15th  OWS  weather  'shop'  as  a  unit,  as  well  as  the  'swimming  pool'  group 
consisting  of  the  'front  office'  WX  officer  and  the  flight  managers  (FM's). 

•  Organization:  This  level  of  granularity  encompasses  the  entirety  of  TACC  as  a  mission  planning  / 
supervising  entity.  In  GAMAT  Phase  I  this  level  of  granularity  was  addressed  only  in  the  context  of 
the  late-stage  assignment  to  examine  the  whole  of  TACC  mission  operations. 

The  Phase  II  GAMAT  effort  can  be  characterized  in  similar  terms  as  follows: 

•  Individual  User.  In  the  case  of  GAMAT  Phase  II,  this  was  the  granularity  at  which  we  framed  the 
flight  planning  analysis  /  designs,  the  WCSS-GWM  evaluations,  our  examination  of  DIP  shop 
operations,  and  our  limited  examination  of  mission  planning  functions. 

•  Group  /  Cluster  of  Users:  In  the  case  of  GAMAT  Phase  II,  it  was  this  level  of  granularity  at  which 
we  considered  the  MP  /  FP  /  DIP  functional  'cluster'  and  the  interactions  among  the  positions  in  the 
execution  cell. 

•  Organization:  In  GAMAT  Phase  II  this  level  of  granularity  was  addressed  as  the  context  for 
information  technology  (IT)  innovations  and  interventions  affecting  multiple  TACC  units  as  well  as 
the  grounds  for  revising  the  number  and  type  of  specific  interface  concepts  comprising  our  proposed 
suite  of  WCSS. 


The  Phase  II  Effort  in  Terms  of  TACC  Mission  Process  Paths 

Beginning  in  2000,  AMC/  TACC  undertook  a  major  initiative  to  redesign  their  organization  and  work 
practices  to  better  meet  the  demands  of  modem  air  transport  operations.  One  aspect  of  this  initiative 
was  to  formulate  and  implement  the  concept  of  integrated  flight  management  (IFM)  and  the  role  of  the 
flight  managers  (FM's).  The  FM  concept  was  based  on  dispatchers  in  commercial  airline  operations.  At 
this  point  in  time,  the  IFM  concept  is  only  partially  implemented  within  TACC.  Although  the 
proportion  of  'flight-managed'  missions  has  grown  substantially  in  the  3  years  since  the  first  cadre  of  6 
FM's  began  working  in  2000,  it  still  accounts  for  a  minority  of  all  TACC  missions. 

The  point  of  relevance  is  that  for  the  time  being  and  for  the  foreseeable  future,  TACC  will  be  processing 
missions  and  flights  through  two  distinct  work  process  paths.  The  first  is  the  current  version  of  the 
'traditional'  path,  leading  from  mission  planning  through  flight  planning  to  execution  and  flight 
monitoring.  The  second  is  the  IFM  path,  leading  from  mission  planning  through  the  FM  staff  to 
execution  and  flight  monitoring.  Both  paths  originate  with  the  mission  planning  shops.  They  converge 
again  in  the  execution  cell.  The  details  of  each  path’s  middle  portion  describe  the  main  divergence 
between  them. 
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Our  earlier  projects  had  focused  on  one  or  the  other  process  path  (for  those  efforts  in  which  our  subjects 
were  dedicated  to  only  one).  The  HIS  A  project's  focus  on  channel  mission  planning  predated  the 
implementation  of  the  IFM  concept,  and  hence  concentrated  on  the  'traditional'  process  path.  The  IFM 
project,  on  the  other  hand,  concentrated  on  the  new  way  of  doing  things.  To  the  extent  it  related  to  one 
versus  the  other,  the  GAMAT  Phase  I  effort  focused  more  on  the  IFM  path  than  the  traditional  one  (e.g., 
in  analyzing  the  work  of  the  'front  office'  WX  officer  working  with  the  FM's  in  the  'swimming  pool'). 
However,  because  the  WX  shop  supports  both  the  traditional  and  the  IFM  branches  of  the  TACC 
workflow,  the  results  of  GAMAT  Phase  I  are  essentially  neutral  with  respect  to  the  interpath  distinction. 

The  new  design  aspects  of  the  GAMAT  Phase  II  effort  focused  upon  flight  planning  and  upon  overall 
TACC  collaboration.  In  subsequent  chapters  of  this  report,  we  shall  examine  each  of  these  aspects  in 
turn.  Chapter  1.3  will  discuss  our  work  with  respect  to  overall  TACC  collaboration.  Chapter  1.4  will 
discuss  the  generation  of  new  WCSS  design  concepts  specifically  tailored  to  flight  planning  and  related 
TACC  functions.  Chapters  1.5  and  1.6  will  introduce  and  discuss  WCSS  design  innovations  generated 
in  response  to  these  topics. 
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1.3  Analysis  of  TACC  Flight  Planning-related  Collaborative  Work 


This  chapter  will  address  our  GAMAT  Phase  II  work  insofar  as  it  relates  to  collaboration  among  TACC 
units  and  for  TACC  as  a  whole.  Given  our  customer-specified  focus  on  flight  planning  operations,  our 
consideration  of  collaboration  issues  concentrated  on  the  interactions  and  interdependencies  among 
flight  planners  (FP's)  and  others  within  the  TACC. 

Beginning  in  1999,  AFRL  has  conducted  a  series  of  projects  focused  on  TACC  mission  processes  and 
tasks  (HIS A,  IFM,  GAMAT  Phase  I,  GAMAT  Phase  II).  Each  of  the  pre-Phase  II  projects  were 
directed  toward  one  or  another  particular  function  or  position  within  the  many  comprising  TACC 
(mission  planners  in  HISA;  FM's  in  IFM;  WX  staff  in  GAMAT  Phase  I).  With  GAMAT  Phase  II  we 
more  or  less  'filled  in  the  final  gaps'  in  our  perusal  of  the  core  TACC  mission  process  path  by  examining 
the  flight  planners,  the  DIP  planners,  and  the  recently-implemented  Execution  Cell.  This  is  not  to  say 
that  we  have  a  complete  understanding  of  the  complexities  of  TACC  and  its  operations.  However,  it  is 
fair  to  say  that  with  Phase  II  we  have  assembled  an  overview  of  the  mainline  operations.  This  means 
that  it  was  not  until  Phase  II  that  we  could  reasonably  evaluate  the  current  and  potential  nature  of 
collaborative  work  in  TACC. 


TACC's  Organizational  Structure  and  the  Prospects  for  Collaboration 

'Collaboration'  is  one  of  those  terms  which  can  be  trivialized  into  a  generic  'good  thing'.  In  colloquial 
usage,  it  carries  the  connotation  of  'multiple  people  working  together  on  a  common  work  product'.  In 
some  sense,  and  at  some  level  of  granularity,  all  organizations  can  be  construed  as  relying  upon 
'collaboration'  in  this  sense.  The  prospects  for  fostering  more  or  better  collaboration  within  an 
organization  are  not  uniform  or  universal.  For  one  thing,  some  work  processes  are  more  amenable  to 
collective  or  group  cooperative  tasking  than  others.  Moreover,  some  organizations  may  have  sound 
reasons  (e.g.,  security;  resource  issues)  which  lead  them  to  enforce  relatively  compartmentalized 
approaches  to  work  processes  of  joint  production  by  multiple  players. 

The  fact  remains  that  there  are  some  activities  where  subsidiary  tasks  are  sufficiently  well-defined  as  to 
be  most  efficiently  accomplished  by  specialized  individuals  (or  sets  of  individuals),  operating  in  relative 
isolation  from  peers  or  parallel  persons,  contributing  to  the  same  overall  process  or  product.  Even  in 
such  cases  as  these,  there  may  still  be  grounds  for  promoting  'collaboration',  but  in  a  sense  other  than 
'multiple  people  working  on  a  common  work  product'.  This  variant  occurs  when  the  otherwise- 
compartmentalized  functions,  no  matter  how  efficiently  conducted  in  and  of  themselves,  must  contend 
with  conditions  and  constraints  relating  to  other  peer  functions  (and  /  or  external  conditions  mediated  by 
peer  functions).  In  such  cases,  the  point  is  to  ensure  that  each  of  the  compartmentalized  subunits  do  not 
separately  and  efficiently  contribute  to  a  work  product  which  is  'wrong'  (i.e.,  ineffective)  when  evaluated 
as  a  composite  output.  The  usual  label  for  keeping  individually-functioning  peer  elements  jointly- 
informed  on  what  and  how  to  accomplish  the  team's  work  is  'coordination'. 
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TACC  is  a  large  organization  subdivided  into  several  functional  subunits.  These  subunits  are  delineated 
with  respect  to  particular  roles  within  or  aspects  of  the  progression  from  initial  mission  plan  through  to 
mission  execution.  This  organizational  architecture  therefore  compartmentalizes  the  participating  staff 
within  specialized  subcomponents  of  the  overall  TACC  team.  This  leads  to  a  corresponding 
compartmentalization  of  functions  and  responsibilities  along  the  timeline  leading  from  mission  planning 
through  to  execution.  In  effect,  TACC  is  currently  configured  in  a  manner  which  does  not  promote 
multiple  staffers  working  together  on  a  common  work  product  in  realtime  or  even  in  near-realtime.  The 
implication  is  that  TACC  (as  currently  configured)  functions  on  the  basis  of  common  effort,  but  not 
through  any  comprehensive  'collaboration'  in  the  sense  typically  attributed  that  term.  To  be  sure,  there 
are  particularly  junctures  in  the  TACC  process  path  where  individuals  within  functional  subunits  (e.g., 
the  flight  planning  shop;  the  former  'swimming  pool'  for  the  FM's)  confer  or  cooperate.  However,  even 
at  these  finer-grained  levels  of  granularity  there  are  few  persistent  examples  of  multi-person 
'collaboration'  to  be  found.2 

By  the  same  token,  all  these  relatively  compartmentalized  individuals  and  subunits  must  make  decisions 
whose  correctness  is  predicated  on  what  others  are  doing,  have  done,  or  will  do.  Furthermore,  each  of 
these  individuals  must  be  prepared  to  modify  mission  plans  in  response  to  changes  resulting  from  the 
actions  of  their  peers  (and,  of  course,  external  parties  for  which  peers  are  the  primary  points  of  contact). 
The  single  most  common  resolvable  breakdown  condition  cited  over  the  years  we've  been  studying 
TACC  is  that  which  occurs  when  one  or  another  aspect  of  a  mission's  plan  is  invalidated  without  the 
person(s)  responsible  for  necessary  corrections  knowing  it.  In  other  words,  the  solution  path  for 
optimizing  TACC  team  operations  is  more  along  the  lines  of  facilitating  'coordination'  among 
individually-specialized  elements  than  instituting  literal  'collaboration'  among  them. 

As  a  result,  our  Phase  II  GAMAT  collaboration  work  has  not  focused  on  design  concepts  specifically 
tailored  to  multiple  people  'collaborating'  in  realtime.  Instead,  we  have  concentrated  on  design  concepts 
which  permit  multiple  players  (perhaps  in  widely-separated  locations)  to  jointly  view  and  /  or 
manipulate  relevant  mission  information.  In  other  words,  we  have  sought  to  support  overall  team  work 
processing  without  configuring  our  designs  such  that  team  members  must  link  up  synchronously  to 
exploit  these  design  concepts.  Conversely,  the  design  concepts  have  been  developed  so  as  to  avoid 
preventing  or  ruling  out  realtime  'collaboration'  among  team  members.  The  point  is  that  we  have 
deliberately  avoided  forcing  realtime  collaboration  among  TACC  team  members  in  our  design  work. 


The  Role  of  Flight  Planning  in  TACC  Collaborative  Work 

TACC  functions  as  the  central  planning  and  supervisory  nexus  for  USAF  airlift  operations.  Internally, 
the  TACC  is  subdivided  into  multiple  subunits,  each  with  its  own  specialized  function.  All  these 
subunits,  however,  contribute  to  an  overall  work  flow  which  leads  from  initial  mission  planning  through 
to  monitoring  of  missions  in  flight.  At  the  'upstream'  end  of  this  work  flow,  planning  concentrates  on 
incoming  requirements  for  movement  of  materiel  and  generates  basic  specifications  for  discrete  actions 
to  effectuate  these  movements.  Loosely  speaking,  this  can  be  seen  as  dealing  with  the  'theory'  of  a 


2  The  primary  exception  to  this  claim  is  to  be  found  in  the  Execution  Cell  (i.e.,  on  the  'Ops  Floor'),  where  a  confederation  of 
specialists  work  jointly  to  oversee  missions  in  flight.  Even  in  this  case,  however,  the  idea  of  a  persistent  sub-team  working  a 
particular  mission  is  neither  the  rule  nor  a  practical  prospect. 
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mission.  At  the  'downstream'  end  the  actual  flights  by  which  the  movements  are  effectuated  are 
overseen.  Loosely  speaking,  this  can  be  seen  as  dealing  with  the  actual  'practice'  of  executing  a  mission. 

The  flight  planning  function  lies  in  the  middle  of  this  work  flow  progression.  This  middle  position  in 
the  sequence  of  case  (mission)  processing  is  reflected  in  flight  planning's  centrality  to  the  entire 
operation.  More  specifically,  flight  planning  represents  the  point  within  the  plan-to-execution 
progression  at  which: 

•  a  mission's  'theory'  becomes  converted  into  a  concrete  specification  for  transport  'practice' 

•  the  planning  context  shifts  from  abstractions  or  categories  (e.g.,  aircraft  type)  to  concrete  specifics 

•  functional  constraints  extrinsic  to  AMC  (and  even  USAF)  must  be  considered  and  dealt  with 

•  legal  and  regulatory  constraints  (e.g.,  ATC  rules)  extrinsic  to  AMC  (and  even  USAF)  must  be 
considered  and  dealt  with 

•  resource  constraints  (e.g.,  fueling)  must  be  assessed  and  planned  for 

•  temporal  issues  (e.g.,  scheduling  details)  must  be  evaluated  and  accounted  for 

•  short-term  dynamic  constraints  (e.g.,  weather)  can  first  be  encountered 

•  planners  must  operate  within  a  problem  space  where  the  constraints  and  rules  might  be  shifting  at 
any  time 

•  TACC  personnel  actively  undertake  a  task  which  the  aircrew  must  accomplish  before  taking  off 

•  the  sort  of  details  or  specifics  with  which  the  execution  cell  and  aircrews  must  grapple  are  first 
locked  in 

•  primary  IT  support  shifts  from  CAMPS  to  GDSS 


In  other  words,  although  all  phases  of  the  plan-to-execution  progression  are  important,  flight  planning 
stands  out  as  the  best  nominee  for  'most  critical  juncture'  in  the  entire  process.  One  can  conceive  of  an 
aircrew  taking  off  on  a  'null  transport  mission'  (i.e.,  one  accomplishing  no  'transport  mission  objective'), 
but  still  requiring  a  flight  plan  to  do  so.  Conversely,  one  cannot  conceive  of  executing  a  transport 
mission  objective  without  having  a  flight  plan  detailing  how  it's  to  be  accomplished. 

Temporal  Issues  In  TACC  Collaboration 

During  the  course  of  our  GAMAT  Phase  II  work,  we  repeatedly  encountered  references  to  key 
timeframes  and  time  points  affecting  the  overall  planning  process  and  the  operations  of  the  execution 
cell.  These  temporal  features  generally  related  to  time  constraints  and  practical  guidelines  for  avoiding 
their  impacts.  In  the  planning  phase,  the  most  critical  time  constraints  noted  related  to  the  DIP  clearance 
process. 
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The  tables  below  summarize  some  of  the  timeframe  and  time  point  parameters  cited  by  subject  matter 
experts  (SME's)  during  the  course  of  our  Phase  II  work,  as  well  as  some  similar  temporal  features 
collected  in  our  earlier  AMC  projects.  The  tables  are  differentiated  on  the  basis  of  the  way  the 
timeframes  are  delineated  by  the  TACC  staffers  who  observe  them.  Some  actions  are  triggered  on  a 
'demand  basis',  and  hence  are  subject  to  consideration  in  terms  of  an  incidental  timeframe.  Some  actions 
are  performed  on  a  recurrent  basis  with  regard  to  a  particular  periodicity  (e.g.,  every  X  hours).  Some  are 
performed  with  respect  to  a  look-ahead  period  into  the  future.  Finally,  some  are  performed  with  respect 
to  a  given  length  of  time  prior  to  an  expected  future  event  (most  commonly  a  mission's  /  sortie's  take 
off)-  All  of  these  categories  involve  organizing  work  with  respect  to  temporal  features,  but  each  is 
distinct  from  the  others  in  the  way  in  which  it  is  defined  with  respect  to  a  timeline. 

The  point  in  enumerating  these  categories  and  the  various  activities  correlated  with  each  of  them  is  to 
illustrate  the  diversity  of  temporal  references  'in  play'  among  TACC  operations.  For  some  tasks,  a  given 
staffer  is  orienting  with  respect  to  a  fixed  time  point  on  the  clock,  whereas  for  others  he  /  she  may  be 
orienting  to  a  more  fluid  expanse  of  time.  For  many  (most  particularly  the  'incidental'  ones),  he  /  she  is 
incapable  of  organizing  the  work  and  must  address  the  given  issue  or  task  as  it  pops  up.  The  diversity  of 
observed  timeframes,  plus  the  proportion  of  tasks  inimical  to  temporal  organization,  illustrates  the 
potential  for  conflicting  temporal  priorities  among  TACC  workers. 

The  first  category,  illustrated  in  Table  1.3-1,  subsumes  those  activities  which  are  conducted  on  an  'on- 
demand'  or  'as  able’  basis.  Relative  to  the  other  categories  and  tables,  this  one  is  clearly  the  largest.  This 
implies  that  'incidental'  tasks  are  the  largest  category  of  tasks  (as  delimited  with  respect  to  timeframes). 
This  in  turn  implies  that  TACC’s  overall  work  processes  are  subject  to  variations  in  terms  of  loads, 
priorities,  and  attendant  stressors  depending  on  circumstances.  All  this  validates  the  informal 
impression  that  TACC  activities  are  to  a  large  extent  'reactive'  -  both  in  terms  of  reacting  to  pop-up 
requirements  and  in  terms  of  reacting  as  one  is  able. 


11 


Table  1.3-1  Examples  of  Incedental  Timeframes  in  TACC  Work 


TIMEFRAME 


ROLE 


Mission  Planner 


Mission  Planner 


Mission  Planner 


As  able 


As  needed 


As  needed 


As  needed,  no  Mission  Planner 

later  than  T-24 

Hours 


As  able 


As  able 


As  able  Flight  Planner 


ACTION /  EVENT 


Begin  mission  planning  actions  on  a  newly-posted  mission. 


Issue  request  for  DIP  clearances  on  a  given  mission  being  planned 


Issue  request  for  notional  flight  plan  to  the  flight  planning  sho 


Issue  request  for  PPR  clearances  on  a  given  mission  being  planned 


Accrete  ('publish')  mission  plan  to  GDSS 


Process  Mission  Planner  request  for  a  notional  flight  plan 


Begin  flight  planning  actions  on  a  mission  /  sortie  in  the  pending 


As  needed 


As  able 


As  able 


Flight  Planner 


Issue  request  for  DIP  clearances  on  a  given  mission  being  planned 


Accrete  fully  developed  flight  plan  to  TACC  info  systems  and 


On  Demand  DIP  Shop  (cell 
changes) 


As  able 


As  happens 


As  needed 


As  needed 


As  needed 


As  able 


3-4  times  daily 


8  times  daily 


As  able 


ACFP  ‘F2’ 

Database 

Maintainer 


ACFP  ‘F2’ 

Database 

Maintainer 


ACFP  ‘F2’ 

Database 

Maintainer 


ACFP  ‘F2’ 

Database 

Maintainer 


ACFP  ‘F2’ 

Database 

Maintainer 


ACFP  ‘F2’ 

Database 

Maintainer 


ACFP  ‘F2’ 

Database 

Maintainer 


Flight  Manager 


As  needed 


As  able 


As  needed  Execution  cell 


\mmm 

\mmm 


On  Demand 


On  Demand 


Execution  cell 


Execution  cell 


resources 


Process  Mission  Planner  request  for  DIP  clearances 


Process  DIP  clearance  requests  deriving  from  cell  changes 


Follow  up  on  DIP  clearance  requests  still  awaiting  response  from 
foreign  granting  authority. 


Receive  info  on  DAFIF-relevant  changes  from  contacts  (e.g., 
FM's,  ATC  authorities)1 


Contact  NIMA  to  request  updates  to  DAFIF  info  to  reflect  changes 
he's  uncovered  from  other  sources.2 * 4 


Review  nominated  route  specifications  for  inclusion  into  the  F2 
database 


Accrete  nominated  route  specifications  into  the  F2  database. 


Review  and  evaluate  stored  F2  route  specifications  for 
modification(s)  and  /  or  retention. 


Typical  frequency  of  updates  to  F2  DB 


Maximum  estimated  frequency  of  updates  to  F2  DB 


Issue  flight  plan  specification  to  relevant  ATC  authority(-ies)  for 
approval 


Revise  flight  plan  in  response  to  negative  feedback  from  ATC 


'Paper  the  crew' 


Take  action  to  attempt  to  correct  mission  problems  identified 
during  the  pre-launch  'scrub'. 


React  to  pop-up  issues  with  missions  being  executed. 


Undertake  re-planning  on  missions  that  cannot  be  completed  in 


1  Source:  Roth  (2003,  October) 

2  Source:  Roth  (2003,  October) 

J  Source:  Roth  (2003,  October) 

4  Source:  Roth  (2003,  October) 
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The  second  category,  illustrated  in  Table  1.3-2,  subsumes  those  activities  which  are  conducted  on 
recurrent  basis  that  is  delineated  with  respect  to  a  discrete  period  of  time.  Relative  to  the  other 
categories  and  tables,  this  one  is  clearly  the  smallest.  This  implies  that  'cyclical'  tasks  are  the  category 
least  likely  to  be  prescribed  in  a  work  domain  as  fluid  as  mission  planning  and  monitoring.  This  in  turn 
implies  that  TACC's  overall  ability  to  control  loads,  priorities,  and  attendant  stressors  through 
specification  of  cyclical  or  recurrent  standardized  tasking  is  very  limited. 


13 


Table  1.3-2:  Examples  of  Recurrent  Timeframes  in  TACC  Work 


TIMEFRAME 


ROLE 


Recurrent  /  Cyclical  Timeframes: 

These  subsume  those  requirements  and  activities  done 
respect  to  a  given  time  span  or  periodicity. 


Every  28  days 

F2  Database  Manager 

Every  28  days 

F2  Database  Manager 

Every  28  days 

F2  Database  Manager 

Every  12  hours 

Flight  Planners  /  FM's 

Beginning  of  each  shift 

Flight  Planners 

Beginning  of  each  shift 

Flight  Planners 

Beginning  of  each  shift 

Flight  Managers 

Every  6  hours 

WX  -  Chartmaker 

Every  6  hours 

WX  -  Chartmaker 

Hourly 

WX  -  Chartmaker 

ACTION  /  EVENT 


on  a  continuous  /  cyclical  basis,  delineated  with 


Nominal  /  official  cycle  time  for  updating 
DAFIF  data. 1 


Nominal  /  official  cycle  time  for  refreshing 
F2  DB.2 


Nominal  cycle  time  for  updating  'canned 
flight  plans'  posted  to  bulletin  board.3 


Cycle  time  for  assignment  of  current  North 
Atlantic  Tracks  (NAT's).4 


Do  'sort'  of  allocated  missions  listing  for 
work  assignments  within  FP  shop.5 


Selection  of  appropriate  NAT  for  the  day's 
flight  planning  of  transatlantic  missions.6 


WX  briefin 


Update  all  charts  for  areas  in  which  IFM 
missions  are  scheduled  to  operate. 


Update  all  charts  for  areas  in  which  IFM 
missions  are  scheduled  to  operate. 


'Trip  around  the  world'  -  General  metwatch 
review  and  assessment 


1  Source:  KA  visit  to  XOCZ,  December  2002;  Roth  (2003,  March). 

2  Source:  KA  visit  to  XOCZ,  December  2002. 

3  Source:  Roth  (2003,  March). 

4  Source:  KA  visit  to  XOCZ,  December  2002. 

5  Source:  KA  visit  to  XOCZ,  December  2002. 

"  Source:  Koth  (2003,  March).  The  SME  stated  this  selection  is  done  'at  the  start  of  each  day'.  Given  the 
12-hour  cycle  time  for  updating  NAT  specifications,  it  is  assumed  he  was  referring  to  the  start  of 'one's 
work  day'  (i.e.,  a  shift)  rather  than  a  24-hour  period. 
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The  third  category,  illustrated  in  Table  1.3-3,  subsumes  those  activities  which  are  conducted  in 
accordance  with  a  time  point  delineated  with  respect  to  a  discrete  period  of  time  extending  into  the 
future.  To  date,  the  'chartmakers'  in  the  weather  back  shop  are  the  primary  category  of  TACC  staffers 
whose  work  is  clearly  delineated  in  this  fashion.  This  is  not  really  surprising,  given  that  the  WX 
chartmakers  are  generating  generic  (non-mission-specific)  information  products  (WX  charts)  for  their 
audience(s).  Their  time  constraints  therefore  relate  to  an  external  and  relatively  unchangeable 
phenomenon  (the  weather)  rather  than  something  subject  to  modification  by  TACC  itself. 
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Table  1.3-3:  Examples  of  'Look-Ahead'  Timeframes  in  TACC  Work 


TIMEFRAME _ ROLE  _ ACTION  /  EVENT _ 


Prospective  /  'Look-Ahead'  Timeframes: 

These  subsume  those  requirements  and  tasks  associated  with  a  given  'look-ahead'  temporal  horizon 
delineated  as  a  time  span  extending  forward  from  the  present _ 


48  hours'  look-ahead 

Ops  Floor  /  'MOG  Meister’ 

Maximum  look-ahead  afforded  by  current 
MOG  tool' 

10  hours'  look-ahead 

Flight  Planner 

Nominal  look-ahead  horizon  for  printing  out 
list  of  allocated  missions  to  be  worked  by 
FP's1 2 

9  to  10  hours'  look-ahead 

WX  -  Chartmaker 

Chartmaker's  stated  look-ahead  time  for 
generating  most  immediate  (6-hour  look 
ahead)  WX  charts. 

0  to  6  hours'  look-ahead 

WX  -  Chartmaker 

Hazard  charts  for  areas  in  which  IFM 
missions  will  operate. 

6  to  12  hours'  look-ahead 

WX  -  Chartmaker 

Hazard  charts  for  areas  in  which  IFM 
missions  will  operate. 

12  to  18  hours'  look-ahead 

WX  -  Chartmaker 

Hazard  charts  for  areas  in  which  IFM 
missions  will  operate. 

18-24  hours'  look-ahead 

WX  -  Chartmaker 

Hazard  charts  for  areas  in  which  IFM 
missions  will  operate. 

1  Source:  Roth  {2003,  October) 

2  Source:  KA  visit  to  XOCZ,  December  2002. 
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Granted,  there  are  other  classes  of  workers  (most  particularly  in  the  Execution  Cell)  who  would  like  to 
be  able  to  conduct  their  work  with  respect  to  such  a  regularized  'look-ahead'  horizon.  However,  those 
other  roles  currently  have  to  try  and  achieve  'look-ahead'  with  respect  to  a  deadline  preceding  a  critical 
event  (most  commonly  mission  /  sortie  launch).  This  type  of  look-ahead  temporal  framing  is  addressed 
in  Table  1.3-4. 
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Table  1.3-4:  Examples  of  Fixed-Point  Prospective  Timeframes  in  TACC  Work 


1  TIMEFRAME 

ROLE 

ACTION /EVENT  1 

Prospective  /  'T-X'  Timeframes: 

These  subsume  those  requirements  and  tasks  associated  with  a  given  'look-ahead'  temporal  horizon 
delineated  with  respect  to  a  particular  time  point  -  mission  /  sortie  launch. 

T-2  or  3  months 

Mission  Planner  (Channel) 

Maximum  lead  time  for  planning  missions 

T-2  or  3  months 

Mission  Planner  (Channel) 

Maximum  lead  time  for  MP  requesting  DIP's 

T-2  Weeks 

DIP  Shop 

Maximum  lead  time  cited  in  XOCZ  KA,  December 

2002 

T-24+  Hours 

DIP  Shop  -  position 
handling  MP  requests 

Process  DIP  requests  from  Mission  Planners 
(generally  presumed  to  be  24  hours  or  more  in 
advance  of  mission  /  sortie  launch). 

T-2 4  Hours 
minimum 

Mission  Planner 

Request  PPR  (Prior  Permission  Required)  clearances 

T-24  Hours 

Mission  Area 

Representative  (MAR) 

MAR  'adoption'  of  mission  under  his  /  her  control  / 
oversight. 

T-24  Hours 

Mission  Planner 

Nominal  timeframe  for  Mission  Planner  'handing  off 
control  of  pending  mission  to  execution  cell  or  FM's. 1 

T-24  Hours 

Ops  Floor  personnel 

Ops  floor  'adoption'  of  mission  for  control  /  oversight 
thereafter.2 

T-24  Hours 
maximum 

DIP  Shop  -  position 
handling  'cell  changes' 

Process  DIP  requests  motivated  by  'cell  changes'  (plan 
modifications  induced  within  24  hours  of  launch). 

T-24  Hours 
maximum 

PPiUSSlHi 

Follow  up  on  outstanding  DIP  requests  relating  to 
missions  /  sorties  scheduled  to  launch  within  24  hours. 

T-10to  T- 12  Hours 
minimum 

Flight  Planners 

Typical  minimum  lead  time  for  FP  planning  actions3 

T-10  to  T-12  Hours 

Flight  Planners 

Typical  timeframe  for  finalizing  FP  and  handing  it  off 
(never  to  be  reviewed  again  by  FP,  barring 
exceptions)4 

T-10  to  T-12  Hours 

Flight  Planners,  Execution 
Cell,  FM's,  Aircrews 

Beginning  of 'blind  spot'  period  between  FP 
finalization  and  mission  launch. 

T-6  Hours 

Flight  Planner 

Absolute  deadline  for  completing  and  exporting  flight 
plans5 

T-6  Hours 

Execution  Cell  -  General 

Conducting  a  precautionary  'scrub'  (review)  of 
missions  lined  up  for  imminent  execution. 

T-6  Hours 

APCC 

Give  final  confirmation  whether  Hazmat  is  involved 
on  a  given  mission. 

T-6  Hours 

APCC 

Give  final  confirmation  of  estimated  aircraft  gross 
weight  on  a  given  mission. 

T-4  to  T-6  Hours 

Flight  Manager 

Begin  construction  of  crew  papers  package. 

1  Source:  Roth  (2003,  March;  2003,  October) 

2  Source:  Roth  (2003,  March;  2003,  October) 

3  Source:  KA  visit  to  XOCZ,  December  2002. 

4  Source:  KA  visit  to  XOCZ,  December  2002. 

5  Source:  KA  visit  to  XOCZ,  December  2002. 


Issues  Deriving  from  Operational  Timeframes  Currently  Observed 

The  timeframe  features  enumerated  in  the  tables  above  serve  to  illustrate  some  of  the  issues  which  cause 
collaboration  and  coordination  problems  for  TACC  personnel.  In  the  subsections  below  we  shall 
illustrate  this  with  some  selected  examples  which  are  clear  enough  to  have  motivated  comments  from 
SME's  during  our  Phase  II  knowledge  acquisition  (KA)  work.  Some  of  these  examples  relate  to 
differences  in  the  timeframes  within  which  different  roles  and  units  operate.  Others  involve  access  to 
information  not  ordinarily  available  within  a  given  role's  timeframe  during  which  that  information 
would  be  useful. 

Two  Flight  Planning  Horizons  with  which  the  Flight  Planners  must  Contend 

One  of  the  things  we  discovered  in  our  flight  planning  KA  is  that  flight  planners  must  deal  with  not  one 
but  two  general  types  of  flight  planning.  The  first,  and  earlier,  one  is  the  generation  of 'notional'  flight 
plans  for  the  benefit  of  the  mission  planners.  This  is  done  to  provide  the  mission  planners  with  what 
might  be  termed  'initial  sketches'  of  prospective  routes  so  that  they  can  evaluate  options,  constraints,  and 
possibilities.  The  most  time-critical  aspect  of  notional  flight  planning  is  that  it  provides  the  mission 
planners  with  the  ability  to  specify  those  nations  for  which  DIP  clearances  must  be  obtained.  Because 
the  DIP  shop  needs  to  be  processing  DIP  requests  1  or  more  days  ahead  of  mission  launch,  this  work 
must  be  initiated  prior  to  the  flight  planners'  nominal  timeframe  for  final  detailed  flight  planning  (which 
can  run  as  little  as  10  -  12  hours  prior  to  launch). 

The  second,  and  subsequent,  type  of  flight  planning  is  of  course  the  final  detailed  plan  creation  one 
typically  associates  with  the  flight  planning  shop.  With  respect  to  those  missions  for  which  notional 
flight  plans  (and  DIP's)  have  already  been  processed,  this  latter  flight  planning  phase  provides  a 
waypoint  at  which  the  flight  planner  can  evaluate  those  earlier  outcomes  with  the  routing  and  scheduling 
details  he  /  she  is  currently  specifying.  The  problem  is  that  the  mission  planning  phase  (and  the 
attendant  DIP  processing)  may  have  been  conducted  quite  some  time  in  advance  of  this  final  flight 
planning  activity.  This  means  that  there  may  have  been  more  than  enough  intervening  time  to  allow  all 
manner  of  relevant  changes  to  have  occurred  which  complicate  or  even  invalidate  the  mission  plan 
parameters  originally  laid  out.  What's  worse  is  that  this  final  flight  planning  activity  is  typically 
undertaken  as  mission  launch  approaches.  This  puts  the  flight  planner  under  heightened  pressure  in  the 
event  problems  are  identified  at  this  relatively  late  date. 

Both  the  notional  and  the  final  flight  planning  activities  involve  recourse  to  ACFP  and  the  production  of 
route  specifications.  The  final  version,  of  course,  involves  considerably  more  fine-grained  detail  and 
presumably  more  flight  planner  time  and  effort.  This  implies  that  to  the  extent  the  relatively  less- 
constrained  and  less-critical  notional  flight  planning  activity  could  be  speeded  up  or  shifted  off  their 
agenda,  the  flight  planners  would  be  freed  up  to  more  effectively  deal  with  their  final  flight  planning. 
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Late  Arrival  of  Relevant  WX  Info  to  Flight  Managers 

In  reviewing  our  WCSS-GWM  prototype  in  September  2003,  flight  managers  mentioned  a  disconnect 
between  their  work  and  that  of  the  WX  shop.  By  the  time  the  flight  managers  get  the  weather  package 
for  a  given  flight  it  is  too  late  for  the  WX  info  to  help  them  in  developing  the  flight  plan  (since  the 
weather  package  typically  is  attached  to  the  crew  papers  after  the  flight  plan  has  been  generated  or 
finalized).3  General  WX  charts  are  being  produced  by  the  WX  back  shop  in  time  to  be  available  during 
the  FM's  typical  planning  timeframe  (circa  T-4  to  T-6  hours).  Unless  they  proactively  seek  out  current 
WX  chart  info,  the  FM's  generally  don't  see  the  WX  data  until  the  relatively  late  point  cited  in  these  KA 
comments.4 


3  Source:  Koth  (2003,  October) 

4  This  is  not  a  new  issue.  During  the  initial  IFM  project  KA  effort  (December  2000),  FM's  were  observed  to  occasionally 
walk  over  to  the  designated  WX  workstation  in  the  'swimming  pool'  and  examine  available  WX  charts  while  the  WX 
specialist  was  away.  During  our  KA  visits  in  the  FY02  GAMAT  Phase  I  effort  we  observed  considerable  conversational 
chatter  between  the  WX  'front  office'  staffer  and  FM's  seated  nearby. 
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Vulnerability  to  Dynamic  Changes  External  to  TACC  /  USAF 

A  recurring  complaint  we've  encountered  dating  back  to  the  HIS  A  project  in  FY99  concerned  the  way  in 
which  shifting  circumstances  outside  the  scope  of  direct  inspection  (and  hence  outside  the  immediate 
ken)  of  TACC  planners  can  'clobber'  a  mission  or  flight  plan.  Such  changes  can  originate  with  any  of 
the  players  associated  with  executing  a  mission,  and  they  may  pop  up  at  any  time.  The  range  of  such 
potential  changes  can  be  illustrated  with  the  following  examples  cited  during  our  Phase  II  KA 
activities:5 

•  Change  requests  incoming  from  the  pilot  /  aircrew 

•  Changes  to  cargo  parameters  (amount;  weight,  etc.) 

•  Changes  relating  to  presence  of  Hazmat  (e.g.,  late  recognition  that  Hazmat  is  involved;  Hazmat 
being  substituted  on  a  priority  basis  for  some  originally-intended  cargo) 

•  Changes  in  DIP  clearance  viability  or  the  regulatory  bases  for  DIP  clearances 

•  Changes  in  airfield  availability  or  operating  parameters  (e.g.,  via  Notice  to  Airmen  (NOT AM's)) 

•  Changes  in  scheduling  pertaining  to  assets  assigned  to  the  planned  mission  (e.g.,  aircrew,  aircraft, 
specific  cargo  items) 

•  Changes  in  routing  or  scheduling  relating  to  significant  weather  conditions  (e.g.,  tropical  storms) 

•  Changes  in  scheduling  deriving  from  crew  rest  requirements 

•  Changes  in  aircraft  availability  deriving  from  maintenance  requirements 

In  general,  such  dynamic  changes  can  jeopardize  the  viability  of  a  flight  plan  at  any  time  during  the 
planning  /  execution  process.  Such  changes  become  particularly  problematical  as  the  time  for  mission 
launch  draws  near,  because: 

•  It  is  only  at  this  relatively  late  stage  in  the  process  that  certain  key  facts  and  factors  can  be 
determined  with  any  certainty. 

•  It  is  at  this  late  stage  that  opportunities  for  timely  adaptations  capable  of  'saving'  a  mission  plan 
diminish  or  disappear. 

•  The  delay  until  one  can  access  newly-issued  or  updated  information  (e.g.,  new  NOTAM's)  typically 
equals  or  exceeds  the  planning  horizon  at  this  late  stage. 


5  This  illustrative  listing  is  drawn  from  information  gathered  during  GAMAT  Phase  II  KA  efforts  in  December  2002,  March 
2003,  June  2003,  and  October  2003. 
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To  the  extent  it  is  available  at  all,  definitive  information  about  remote  (i.e.,  on-site)  circumstances 
can  sometimes  only  be  obtained  through  direct  contact  with  a  relevant  remote  authority. 


•  Particularly  during  our  Phase  II  timeframe  (with  multiple  overseas  theaters  having  to  be  supported) 
the  opportunities  for  corrective  replanning  had  become  even  more  constrained  owing  to  demands  on 
USAF  assets  (e.g.,  aircraft,  crews).6 

It  is  difficult  to  get  a  sense  of  what  proportion  of  execution-ready  flight  plans  typically  have  to  be  re¬ 
planned  as  mission  launch  time  approaches.  One  of  the  few  clues  we  were  able  to  obtain  came  from  an 
interview  with  the  International  Flight  Plans  and  Diplomatic  Clearance  Office’s  (XOCZ)  Major  Barton. 
He  noted  that  during  a  6-hour  shift  on  a  recent  day  there  had  been  a  total  of  some  70  flight  plans  to 
execute,  while  there  were  some  19  material  changes  that  had  to  be  processed.  Even  if  this  frequency  of 
replanning  were  double  the  'norm',  it  would  insinuate  a  replanning  incidence  of  at  least  13%  of  pending 
missions. 

To  deal  with  such  changes  under  time  pressure,  TACC  staffers  must  obtain  relevant  or  current  data  from 
authoritative  sources.  For  factors  such  as  those  addressed  in  this  subsection,  such  authoritative  sources 
are  external  to  TACC  itself.  This  means  that  external  contacts  are  an  important  tactic  in  trying  to  keep 
up  with  events  and  conditions.  We  have  seen  such  external  contacts  employed  in  most  of  the  TACC 
units  we've  studied  over  the  last  4  years.  In  the  IFM  project  (FY01)  we  observed  FM's  repeatedly  taking 
the  time  to  call  ATC  and  on-site  airfield  centers  to  double-check  on  conditions,  constraints,  etc.  In  the 
GAM  AT  Phase  I  project  (FY02)  the  staffers  performing  the  WX  'chartmaker'  role  consistently 
mentioned  the  occasional  need  to  seek  detailed  on-site  (e.g.,  airfield)  data,  even  at  the  cost  of  a  direct 
contact.  For  the  flight  planners,  email  to  and  from  Euro  Control  and  /  or  UK  ATC  is  a  common  channel 
used  to  double-check  on  conditions  and  changes  for  the  all-important  European  airspace.7  The 
importance  of  such  external  contacts  to  the  DIP  planners  is  evidenced  by  their  habit  of  maintaining 
'contacts  folders'  containing  key  contact  data.8 


6  Source:  Interview  with  Major  Barton  of  XOCZ  (Roth:  2003,  March). 

7  Although  both  Euro  Control  and  UK  authorities  issue  regularly-updated  routing  data  in  the  form  of  the  Route  Access 
Document  (RAD),  there  are  still  cases  in  which  the  cycle  time  for  updating  the  RAD  exceeds  the  timely  planning  horizon  for 
the  flight  planner.  (Source:  KA  with  XOCZ,  December  2002). 

8  These  contact  folders  include  such  things  as  FSG  information  on  DIP  requirements  for  the  given  country,  numbers  of 
blanket  clearances  available,  Hazmat  requirements  and  rules,  phone  numbers  for  key  DIP  authorities,  contact  number  for  the 
U.S.  Embassy  DAO  office  in  that  country,  and  miscellaneous  other  remarks  as  necessary.  (Roth:  2003,  March) 
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Timely  Availability  of  APCC-Supplied  Data  to  Flight  Planners  /  Flight  Managers 

The  ACFP  route  generation  algorithms  were  designed  to  optimize  their  outputs  with  regard  to  predicted 
fuel  consumption.  The  rate  of  aircraft  fuel  consumption  is  contingent  upon  aircraft  gross  weight,  which 
in  turn  is  dependent  on  the  weight  of  the  cargo  the  aircraft  is  hauling.  Furthermore,  a  variety  of  routing 
constraints  may  or  may  not  be  applicable  depending  on  the  presence  of  hazardous  material  (Hazmat) 
within  a  given  mission's  cargo.  Both  gross  weight  and  Hazmat  involvement  are  parameters  which  must 
be  determined  based  on  information  obtained  from  APCC.  Unfortunately,  neither  of  these  parameters 
can  be  reliably  specified  until  a  matter  of  a  few  hours  prior  to  mission  launch.  In  doing  their  flight 
planning  tasks,  both  flight  planners  and  flight  managers  need  to  know  the  facts  on  these  parameters  as 
early  as  is  feasible.  In  common  practice,  APCC  is  not  able  to  provide  these  facts  with  any  finality  until  a 
point  in  time  (circa  T-4h  to  T-6h  at  the  earliest)  which  is  (a)  'tight'  with  regard  to  the  FM's  timeframe  for 
planning  actions  but  (b)  later  than  the  flight  planners'  typical  timeframe.9 


Recurrent  References  to  Final  Mission  Review  at  Circa  T-6  Hours 

During  our  Phase  II  KA  activities,  we  made  a  point  to  interview  members  of  the  Execution  Cell  to 
gather  information  on  the  culmination  of  the  mission  /  flight  planning  process  in  the  execution  phase. 
One  point  which  repeatedly  came  up  was  the  advisability  of  doing  a  comprehensive  review  and 
assessment  (a  'scrub')  of  all  pending  mission  records  at  about  6  hours  prior  to  mission  launch.  This  was 
intended  to  identify  any  lingering  problems  relating  to  plans  which  may  have  lain  unreviewed  for 
several  hours. 

This  approximate  T-6h  timeframe  kept  arising  in  comments  and  facts  surrounding  the  progression  from 
the  planning  phase  to  the  execution  phase.  The  following  events  are  some  of  the  more  significant  ones 
which  cluster  around  this  same  temporal  waypoint: 

•  The  latest  'deadline'  quoted  by  the  flight  planners  for  their  finalization  of  flight  plans 

•  The  general  forecast  timeframe  for  the  latest  charts  from  the  WX  shop 

•  Nominal  deadline  for  APCC  final  confirmation  of  aircraft  weight 

•  Nominal  deadline  for  APCC  final  confirmation  of  Hazmat  among  the  mission  cargo 

•  Nominal  time  at  which  FM’s  undertake  their  'paper  the  crew’  tasking  for  a  given  mission 

It  would  seem  that  it  is  in  the  vicinity  of  this  T-6h  timeframe  that  various  TACC  units  and  roles  perceive 
a  sort  of  'last  chance'  juncture  at  which  problems  with  a  pending  mission  might  be  caught  and 
conceivably  resolved.  Similarly,  it  is  not  until  this  approximate  juncture  that  all  TACC-provided 
information  (e.g.,  WX  charts,  final  APCC  confirmations  on  Hazmat  and  weight)  is  expected  to  be  finally 
specified. 


9  This  is  not  a  new  issue.  During  the  initial  IFM  project  KA  effort  (December  2000),  FM's  were  observed  to  consistently 
have  to  wait  on  APCC  to  provide  them  with  final  or  reliable  weight  specifications  and  /  or  Hazmat  indications. 
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It  is  interesting  to  note  that  this  approximate  T-6h  timeframe  lies  in  a  sort  of  'gap'  between  the  nominal 
finalization  of  a  flight  plan  in  the  flight  planning  shop  and  the  formally-prescribed  'uptake'  of  the 
mission  by  the  Execution  Cell.  It  is  the  personnel  on  the  'downstream'  side  who  must  deal  with  the 
ramifications  of  any  problems  (i.e.,  the  Execution  Cell  staff)  who  have  made  a  point  to  do  reviews  at  this 
time.  It  is  not  surprising  that  the  final  IFM  process  typically  gets  underway  at  this  same  time,  because 
it's  not  until  then  that  an  FM  can  reasonably  expect  to  have  all  the  relevant  information  on  hand. 
Because  FM's  are  trained  to  refine  (or  even  generate  from  scratch)  mission  flight  plans,  the  IFM  process 
effectively  involves  a  shift  in  the  flight  planning  function  later  in  the  process  path  to  a  point  where  it 
intersects  this  seemingly  critical  timeframe. 

All  these  facts  point  to  a  need  to  support  TACC  staff  at  this  critical  juncture.  One  might  well  suggest 
that  some  form  of  organizational  adjustment  (e.g.,  role  redefinition;  procedural  changes)  might  be  the 
most  effective  way  to  provide  better  coverage  at  this  point  in  the  process  path.  However,  such 
interventions  are  beyond  the  scope  of  our  GAMAT  mandate,  and  we  shall  not  pursue  their  possibilities 
within  this  report.  Within  the  framework  of  current  TACC  roles  and  procedures,  the  most  readily 
available  solution  path  is  to  provide  integrated  information  assets  affording  the  entire  set  of  relevant 
planning,  execution,  and  parallel  (e.g.,  DIP,  APCC)  staffers  the  ability  to  obtain  and  maintain  situation 
awareness  on  the  status  of  a  pending  mission. 


Collaborative  Information  Technology  (IT)  Issues 

This  section  will  present  those  aspects  of  our  GAMAT  Phase  II  work  which  addressed  the  tools  through 
which  TACC  collaborative  work  was,  is,  and  /  or  could  be  conducted.  The  topics  discussed  herein  will 
include  parallel  efforts  and  developments  which  affect  the  IT  context  for  implementing  flight  planning 
WCSS. 

Ongoing  Evolution  in  TACC  Systems 

AMC's  internal  information  systems  continue  to  evolve.  This  evolution  has  had,  and  will  continue  to 
have,  notable  impacts  on  those  TACC  functions  upon  which  we  focused  in  our  Phase  II  work.  The 
primary  developments  having  a  bearing  on  our  subject  matter  include: 

•  GDSS-2  Development.  The  evolution  of  GDSS  into  GDSS-2  is  more  than  a  major  upgrade.  GDSS- 
2  will  in  effect  be  a  whole  new  system,  with  new  features  and  an  overall  configuration  distinct  from 
its  predecessor.  Because  GDSS-2  is  still  in  the  process  of  being  developed  and  delivered,  our  Phase 
II  design  concepts  were  generated  without  regard  to  specific  features  of  GDSS-2. 

•  ACFP  Development.  The  ongoing  evolution  of  ACFP  had  already  become  something  of  an  issue 
with  the  flight  planning  staff.  When  we  did  our  initial  flight  planning  KA  in  December  2002,  we 
were  told  that  the  flight  planning  shop  was  deliberately  using  ACFP  2.5  (rather  than  the  already- 
available  ACFP  3.0)  owing  to  a  shift  in  certain  features  and  functionalities  with  the  newer  version. 
This  hasn't  exactly  been  welcomed,  because  although  the  version  3.0  features  are  more  convenient 
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for  perhaps  90%  of  the  users  (most  of  whom  are  not  in  the  flight  planning  shop),  who  currently 
perform  only  about  10%  of  the  overall  flight  planning  work. 10 

•  F2  Database  Evolution.  The  F2  Database  is  the  repository  for  route  specifications  available  for 
flight  planners'  subsequent  use.  During  Phase  II  there  was  a  persistent  question  as  to  how  and  in 
what  form  the  F2  Database  (or  an  equivalent  repository  capability)  was  going  to  be  carried  forward. 
This  made  for  uncertainty  with  regard  to  (e.g.)  the  prospects  for  future  route  specification  protocols 
and  formatting,  accessibility  to  the  new  repository,  and  other  such  factors. 


‘Blind  Spots'  in  Current  TACC  IT  Support 

The  relative  compartmentalization  of  TACC  functions  and  personnel  is  reflected  in  a  measure  of 
compartmentalization  in  the  IT  support  tools  provided  to  and  /  or  use  by  a  given  role  or  unit.  As  of 
Phase  II,  only  the  flight  managers  (and  /  or  anyone  else)  using  the  IMT  Dashboard  could  claim  to  have 
persistent  access  to  both  a  summary  display  of  mission  status  parameters  and  automated  support  for 
alerts  and  warnings  on  pop-up  conditions  inimical  to  mission  viability.  Without  this  capability,  TACC 
staffers  may  have  to  proactively  access  one  or  more  IT  assets  to  ascertain  current  mission  parameters  'as 
planned'  and  /  or  additional  data  necessary  to  evaluating  continued  plan  viability. 

The  result  is  a  situation  in  which  TACC  staffers  are  expected  to  maintain  situation  awareness  over  a 
multi-dimensional  problem  space  within  which  relevant  variables  /  factors  are  mutually  constraining. 
The  absence  of  a  'one-stop'  visualization  or  other  display  affording  them  comprehensive  inspection  of 
these  mutually-constraining  factors  individually,  much  less  as  a  composite,  is  one  of  the  key  deficiencies 
in  the  current  TACC  IT  infrastructure. 

The  reason  this  constitutes  a  deficiency  is  that  the  current  situation  not  only  facilitates,  but  practically 
mandates,  certain  'blind  spots'  along  the  TACC  mission  operations  process  path.  By  'blind  spot',  we 
mean  situations  in  which  TACC  staffer  A  lacks  visibility  (or  ready  access  to  visibility)  on  parameters  or 
decision  factors  such  as: 

•  Proactive  modifications  to  an  entire  plan  made  by  peer  staffer(s)  B  (C,  D,. . .)  within  TACC  itself; 

•  Proactive  modifications  to  one  or  another  subsidiary  plan  element  (e.g.,  DIP's;  entry  /  exit  times) 
enacted  by  peer  staffer(s)  B  (C,  D,...)  within  TACC,  and  having  'cascade'  or  derivative  negative 
effects  on  staffer  A's  current  object  of  work; 

•  Proactively-induced  constraints  or  constraint-inducing  conditions  (e.g.,  denials  of  proposed  plans  on 
review;  NOT  AM’s)  deriving  from  actions  by  external  parties  (e.g.,  ATC);  and  /  or 

•  Changes  in  status  or  prospects  in  the  operational  environment  (e.g.,  weather,  MOG)  of  which  staffer 
A  has  no  knowledge. 


10  Source:  KA  visit  to  XOCG,  December  2002. 
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Incorporation  of  NOT  AM  and  DIP  Data 


Our  GAM  AT  Phase  II  effort  was  not  the  only  project  examining  IT  capabilities  of  relevance  to  the  flight 
planning  shop  and  the  flight  planning  process.  There  were  two  other  efforts  being  pursued  by  BBN 
contractors  under  the  aegis  of  integrated  flight  management  advanced  technology  demonstrations 
(ATD's).  As  our  Phase  II  work  got  underway,  we  kept  our  eyes  open  for  opportunities  for  linking  into 
these  two  external  projects. 

One  of  these  projects  was  the  development  of  a  prototype  DIP  'lead  time  generator'  tool.11  This 
application  was  intended  to  calculate  the  'lead  time'  pertaining  to  a  prospective  DIP  needed  for  a  given 
nation.  This  is  important  to  mission  /  flight  planning  because  DIP  processing  must  be  done  with  respect 
to  predetermined  timeframes  which  may  end  up  being  the  deciding  constraints  on  whether  a  mission  or 
flight  plan  can  be  (or  still  is)  feasible.  At  the  present  time,  there’s  no  reliable  method  of  ascertaining  DIP 
lead  times  without  checking  information  in  the  Foreign  Clearance  Guide  (FCG).  The  FCG  is  available 
in  the  form  of  hardcopy  manuals  situated  in  the  DIP  shop.  This  means  that  checking  on  DIP  lead  times 
requires  personal  contact  (including  email  or  other  messaging)  and  hence  delays  a  planner's  continuation 
of  his  /  her  work.  Ready  access  to  DIP  lead  time  data  would  permit  planners  to  quickly  ascertain 
whether  or  not  it  is  possible  to  obtain  DIP  clearances  in  time  for  a  planned  sortie. 

The  second  project  was  an  initiative  to  prototype  a  Notice  to  Airmen  (NOTAM)  tool.  Currently, 
planners  and  other  personnel  must  proactively  navigate  to  a  website  and  browse  to  find  NOTAM's 
applicable  to  a  given  airfield.  This  is  time-consuming,  burdensome,  and  guaranteed  only  to  provide  the 
user  with  data  posted  as  of  the  time  of  his  /  her  inquiry.  The  prospective  NOTAM  tool  would  monitor 
NOTAM's  as  they  were  made  available  and  alert  TACC  users  on  new  NOTAM's  having  significance 
with  respect  to  missions  being  planned  and  executed.  This  capability  would  relieve  TACC  staffers 
from  both  (a)  the  mandatory  burden  of  proactive  searching  and  (b)  the  prospect  of  being  'blindsided'  by  a 
NOTAM  posted  after  one  had  last  checked  the  online  repository. 

By  the  close  of  our  Phase  II  effort,  both  these  projects  had  made  significant  headway  on  their  respective 
tasks.  This  meant  that  we  could  reasonably  design  WCSS  concepts  which  included  reference  to 
readily-available  DIP  and  NOTAM  data.  The  WCSS  design  concepts  introduced  and  discussed  later  in 
this  report  were  therefore  tailored  to  accommodate  the  products  (extant  and/or  prospective)  from  these 
parallel  efforts. 


Reconfiguring  our  Suite  of  WCSS  Design  Concepts 

The  GAMAT  Phase  II  effort  represented  the  fourth  consecutive  project  in  which  AFRL  researchers  had 
studied  TACC  operations  and  prescribed  innovative  design  concepts.  The  foci  and  the  products  of  these 
earlier  projects  are  summarized  in  Table  1.3-5  below. 


11  t  his  effort  was  labeled  the  'Foreign  Clearance  Guide  Project’.  The  software  application  developed  in  the  course  of  the 
FCG  Project  is  labeled  the  'ACT'  (Automated  Clearance  Tool).  (Cf.  BBN,  2003,  July).  Subsequent  allusions  to  this 
prototype  will  generally  cite  it  as  'lead  time  generator'  or  'lead  time  calculator'  -  the  two  labels  most  commonly  applied  during 
our  Phase  II  work.  This  lead  time  element  is  a  component  of  the  overall  ACT  package  as  described  in  AFRL's  SAB  poster  of 
December  2003  (AFRL,  2003,  December). 
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Table  1.3-5:  Overview  of  Subject  Matter  and  Design  Concepts:  FY99  -  FY02 


PROJECT 

SUBJECTS  STUDIED 

DESIGN  CONCEPTS 

HISA 

FY99-FY00 

•  Channel  mission  planning 

•  MOG 

•  Port  Viewer1 
•Conflict  Summary 

•  'Smart  Lieutenant' 

•  Structured  Listing  of  Pending  Missions  to 
afford  SA  over  the  pending  workstream2 

IFM 

FY01 

•  New  integrated  flight 
management  (IFM)  mode  of 
work 

•  Flight  Managers  (FM's) 

•  Utility  of  IMT  Dashboard 

•  Mission  Summary  Display  (concise  'to-do 
list’  with  alert  cues) 

•  Flight  Planning  Palette3 

GAMAT 

Phase  I 
FY01-FY02 

•  WX  forecasting  and  WX 
support  to  TACC 
•WX  'back'  and  'front'  shops 

•  GWM-WCSS4 

•  Sortie  Palette5 

1  Multiple  prototypes  and  deployed  applications  based  on  the  original  Port  Viewer  concept  have  been 
produced  since  1999.  Additional  labels  for  these  descendants  of  that  inaugural  HISA  product  include: 
'MOG  Tool';  ’MOG  Viewer’;  and  'HISA  Tool'. 

2  This  concept  would  later  be  refined  and  recommended  anew  in  the  form  of  the  Mission  Summary  Display 
in  FYOl’s  IFM  project. 

3  The  Flight  Planning  Palette  was  introduced  as  a  paper  concept  in  the  IFM  project's  final  briefing  (March 
2001).  As  we  learned  in  FY03,  the  FM  staffhad  accepted  this  recommended  concept  and  taken  action  to 
have  it  developed  using  local  resources.  The  result  -  termed  the  'Sortie  Manager'  -  is  now  an  application 
available  for  use  by  the  FM's. 

4  The  GWM-WCSS  was  also  known  (at  various  times  and  by  various  people)  as  Weather  Management  Toll 
(WMT),  the  'Weather  Tool',  etc.  The  original  prototype  (developed  and  refined  by  Dr.  Ron  Scott  and  his 
BBN  colleagues)  has  become  a  deployed  application  within  TACC.  As  such,  the  GWM-WCSS  is  the  sole 
example  to  date  of  an  AFRL  team's  prototype  which  has  itself  migrated  into  deployment  (as  opposed  to 
being  re-implemented  for  deployment). 

5  The  Sortie  Palette  developed  in  the  GAMAT  project  was  an  adaptation  of  the  IFM  project's  Mission 
Summary  Display  concept  implemented  as  an  adjunct  to  the  GWM-WCSS. 
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As  illustrated  in  the  table,  each  of  these  prior  three  projects  focused  on  a  particular  position  or  function 
within  the  overall  TACC  operational  setting.  As  a  result,  each  of  the  design  concepts  generated  within 
these  projects  ended  up  being  tailored  to  the  relatively  narrow  context  each  project's  objectives  and 
knowledge  acquisition  afforded.  Nonetheless,  each  of  the  concepts  has  been  carried  forward  toward 
deployment  and  daily  use  -  some  still  within  the  narrow  scope  of  their  original  presentations,  and  some 
in  relation  to  the  more  general  scope  of  application  which  had  been  intended  originally.  More 
specifically: 

•  HISA's  Port  Viewer  was  originally  one  of  three  'viewers'  comprising  a  comprehensive  mission 
visualization  tool.  It  was  extracted  from  this  larger  set  and  tailored  to  address  the  MOG  problem 
which  our  TACC  customers  specified  as  our  research  focus.  In  its  various  (but  relatively  unvarying) 
incarnations,  this  visualization  tool  has  evolved  into  a  general  purpose  ‘gadget’  employed  by  more 
than  one  role  within  TACC. 

•  The  IFM  project's  Mission  Summary  Display  was  conceived  and  recommended  as  both  (a)  a  specific 
remedy  to  on-screen  visual  overload  problems  identified  with  the  IMT  Dashboard  and  (b)  a  general 
top-level  situation  awareness  aid  of  general  utility  to  all  involved  in  TACC  mission  processing 
operations.  After  the  close  of  the  IFM  project,  this  concept  was  carried  forward  as  (a)  a  specific 
display  option  to  be  implemented  in  the  oncoming  GDSS-2  application  and  (b)  a  general  mission  SA 
aid  associated  with  the  specific  tool  developed  for  the  WX  staff. 

•  The  IFM  project's  Flight  Planning  Palette  was  not  carried  forward  for  prototyping  in  subsequent 
AFRL  projects.  However,  the  intended  users  (the  FM's)  took  it  upon  themselves  to  pursue  the 
concept,  and  they  succeeded  in  getting  it  developed  locally  in  the  form  of  what's  now  called  the 
'Sortie  Manager'. 

•  The  WCSS-GWM  prototype  has  evolved  into  a  general  purpose  WX  visualization  aid  which  has 
been  deployed  for  use  by  TACC  staffers  outside  the  population  of  WX  staffers  for  whom  it  was 
originally  designed. 


These  examples  illustrate  that  even  though  our  earlier  recommendations  were  framed  with  regard  to  one 
or  another  narrowly-delineated  context,  they  were  always  intended  to  be  more  generally  useful.  So  long 
as  we  continued  to  focus  on  a  particular  position  or  function,  our  design  and  prototype  products  could  be 
generated  with  sole  regard  to  the  particulars  of  the  context  at  hand  and  not  the  generalities  of  TACC  as  a 
whole.  In  this  most  recent  project,  we  finally  had  to  confront  the  relationship  between  the  specifics  of 
our  design  concepts  and  the  requirements  of  supporting  multiple  (or  all)  TACC  roles  and  functions 
comprising  the  mission  processing  operations. 

The  GAMAT  Phase  II  effort  marked  the  first  of  our  four  projects  to  date  in  which  the  AFRL  team  was 
asked  to  consider  the  overall  suite  of  IT  support  tools  available  to  TACC  in  light  of  the  overall  TACC 
organization,  work  process,  and  workflow.  This  more  general  scope  of  consideration  required  some 
adaptations  in  the  number  and  the  details  of  our  suite  of  WCSS  design  concepts.  These  adaptations 
became  necessary  because  the  'granularity'  at  which  our  earlier  design  concepts  were  framed  was 
narrower  than  the  'granularity'  at  which  we  now  had  to  assess  the  concepts'  viability  with  respect  to  this 
more  general  scope. 
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As  a  result  of  this  assessment,  it  was  determined  that  the  basic  set  of  capabilities  provided  in  our  earlier 
prototypes  and  concepts  was  still  viable  for  overall  TACC  operations.  However,  some  of  the 
capabilities  were  more  'generic'  than  may  be  evident  in  their  current  associations  with  one  or  another 
specific  position,  deployed  functionality,  and  /  or  prototype.  The  implication  was  that  some  features  or 
capabilities  needed  to  be  re-framed  and  reallocated  into  more  general  forms  as  we  expanded  our  scope 
of  consideration  from  individual  units  to  all  of  TACC.  A  summary  of  the  necessary  adjustments  as  of 
Phase  II  is  given  in  Table  1.3-6. 

Table  1.3-6:  Adapting  Prior  WCSS  Capabilities  to  Address  TACC-Wide 
Operations  and  Team  Collaboration  Requirements 


CAPABILITY 

CURRENT  STATUS 

ADAPTATION  REQUIRED 

Port/MOG 

Visualization 

•  Currently  provided  by  multiple 
MOG  /  Port  Viewer  prototypes 
and  applications 

•  None  (for  MOG  purposes) 

•  Rationale:  Because  MOG  is  a  discrete 
issue,  there  is  no  problem  in  maintaining  a 
distinct  MOG-specific  visualization  tool 

Summary 

Workstream 

Situation 

Awareness 

•  Currently  demonstrated  in  the 
Sortie  Palette  element 
associated  with  the  GWM- 
WCSS 

•  Non-WX-Shop  team  members 
must  monitor  the  pending 
workstream  via  (e.g.)  IMT  or 
GDSS. 

•  Decouple  the  Sortie  Palette  from  its 
current  placement  within  the  GWM- 
WCSS 

•  Establish  the  Sortie  Palette  (or  equivalent) 
as  a  discrete  application  /  aid  within  an 
overall  TACC  collaborative  support  suite 

•  Elevate  this  workstream  aid  to  universal 
access  across  the  TACC  team 

Geospatial 

Visualization 

•  Currently  provided  in  the 
GWM-WCSS  prototype 

•  Offers  composite  visualization 
for  weather  and  route  /  mission 
elements 

•  Current  prototype  is  tailored  to 
WX  needs  and  incorporates 
some  features  /  priorities 
peculiar  to  WX  shop 

•  Migrate  the  general  or  basic  visualization 
capabilities  to  a  discrete  application 
provided  a  wider  population  of  users 

•  Decouple  any  WX-specific  features  or 
options  from  this  more  generic  prototype 

•  Specify  the  layers  and  options  (analogous 
to  those  provided  WX  staff  already) 
which  need  to  be  prioritized  for  flight- 
oriented  visualization 

Single  Flight 
Planning 
Palette  / 
Portal 

•  Currently  available  to  FM’s  in 
the  form  of  the  locally- 
developed  Sortie  Manager 

•  Some  among  the  implemented 
set  of  features  and  options  are 
peculiar  to  FM  needs  and 
functions 

•  Generate  a  more  generic  version  of  the 
Sortie  Manager  application 

•  Decouple  the  FM-specific  options  and 
features  for  this  more  generic  prototype 

DIP  Status 
for  a  Given 
Mission 

•  Currently  available  if  one  can 
find  it  in  the  ffee-form  text 
stored  in  the  given  mission's 
Logbook  (DAP)  records 

•  Current  BBN  ACT  Tool 
provides  prototype  DIP 
processing  tool,  but  doesn't 
provide  general  SA  on  DIP'S  to 
other  TACC  team  members 

•  Generate  a  design  concept  for  a  generic 

DIP  status  display  providing  SA  and 
master  caution  panel  functions  with 
respect  to  diplomatic  clearances 

•  NOTE:  This  generic  SA  aid  neither 
conflicts  with  nor  invalidates  the 
functionalities  represented  by  the  ACT 

Tool.  The  DIP  planners  still  need  a 
detailed  tool  such  as  the  ACT. 
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The  adaptations  cited  in  Table  1.3-6  don't  invalidate  the  functionalities  that  our  AFRL  (and  parallel) 
teams  have  generated  and  demonstrated  in  projects  to  date.  Instead,  the  adaptations  consist  of 
'repackaging'  these  functionalities  to  afford  a  wider  scope  of  deployment  in  support  of  the  overall  TACC 
operational  team.  Phrased  a  different  way,  the  functionalities  developed  so  far  constitute  a  somewhat 
piecemeal  approach  to  identifying  and  mitigating  TACC  needs.  In  moving  forward  to  consider  the 
entirety  of  the  TACC  operational  team  and  their  joint  needs,  we  will  necessarily  have  to  redefine  which 
functionalities  are  to  be  associated  with  which  positions  and  roles.  By  and  large,  this  is  a  matter  of 
generalizing  functionalities  created  with  respect  to  only  one  such  position  /  role  and  recasting  them  in 
broader  terms. 

The  specific  outcomes  of  this  Phase  II  reorientation  will  be  presented  in  Chapters  1 .5  and  1 .6,  where  we 
shall  introduce  and  discuss  the  WCSS  design  concepts  generated  during  GAMAT  Phase  II.  In 
accordance  with  our  assigned  focus,  these  concepts  will  be  framed  with  primary  regard  to  the  flight 
planning  function  (broadly  interpreted).  Before  moving  on  to  Chapters  1.5  and  1.6,  we  shall  review  and 
discuss  the  specific  TACC  role  /  position  upon  which  we  focused  during  Phase  II  (the  flight  planner)  in 
Chapter  1 .4. 
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1.4  Analysis  of  TACC  Flight  Planning  Work 


This  chapter  will  present  those  aspects  of  flight  planning  (as  a  task  and  a  process)  that  were  (a) 
specifically  cited  during  our  Phase  II  GAMAT  KA  work  and  (b)  judged  relevant  to  our  Phase  II  focus  on 
flight  planning.  Some  of  these  items  are  indicative  of  problems  for  which  WCSS  design  intervention 
may  be  appropriate.  Others  are  clues  to  current  or  prospective  features  of  the  TACC  flight  planners' 
role,  functions,  and  /  or  work  ecology.  Examination  and  consideration  of  the  issues  outlined  in  this 
chapter  led  to  our  selection  and  prioritization  of  features  worthy  of  being  implemented  in  our 
recommended  WCSS  interventions. 


Scope  of  Flight  Planners'  Tasking  and  Presumed  Knowledge 

Flight  planning  is  a  complex  decision  making  process  which  must  attempt  to  account  for  a  wide  variety 
of  factors,  many  of  which  are  undetermined  or  indeterminable  at  the  point  the  planner  really  needs  to 
know  them.  The  number  and  variety  of  these  decisive  factors  induces  a  daunting  scope  for  the 
knowledge  and  situation  awareness  an  effective  flight  planner  is  expected  to  have.  Adding  to  this  is  the 
scope  of  oversight  responsibilities  assigned  to  TACC's  flight  planning  staff.  They  must  continuously 
support  Air  National  Guard  and  Reserve  missions  in  addition  to  USAF  ones.  They  must  provide  on- 
demand  planning  support  for  commands  (e.g.,  PACAF)  who  typically  do  their  own  flight  planning.12 
They  serve  as  the  presumptive  'fall-back'  planning  support  unit  for  tough  cases. 

All  this  means  there  is  little  hope  for  precisely  circumscribing  the  flight  planners'  expected  workstream 
and  /  or  the  elements  critical  to  processing  one  or  another  'case'  (i.e.,  mission)  within  that  workstream. 
Beyond  this,  here  is  little  hope  for  precisely  prescribing  the  range  of  knowledge  (both  abstract  and 
experiential)  necessary  for  a  flight  planner  to  be  effective.  This  explains  the  fact  that  significant  hands- 
on  experience  is  claimed  to  be  required  to  get  a  new  flight  planner  'up  to  speed'.13  This  also  explains  the 
fact  that  seasoned  flight  planners  are  ascribed  a  degree  of  personally  accrued  'expertise'  not  widely 
ascribed  to  other  TACC  positions. 


12  PACAF  normally  does  all  its  own  flight  planning  for  missions  executed  within  its  AOR.  However,  for  missions  and  /  or 
mission  assets  outside  this  AOR,  PACAF  routinely  calls  on  TACC's  flight  planners  to  get  involved.  (Source:  KA  with 
XOCZ,  December  2002) 

13  Specifically,  one  SME  claimed  it  took  2  months  of  OJT  plus  6-12  months  of  daily  work  experience  to  achieve  proficiency 
as  a  flight  planner.  (Roth:  2003,  March) 
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Comments  and  Analysis: 


Flight  planners,  like  flight  managers,  are  expected  to  decide  and  document  a  coherent  and  feasible  plan 
in  the  context  of  a  very  messy  and  dynamic  decision  space.  Both  the  missions  they  are  tasked  to  plan 
and  the  factors  impinging  upon  those  missions  often  rely  on  information  'over  the  horizon'  from  the 
flight  planning  shop,  and  even  outside  the  scope  of  TACC  itself.  Owing  to  their  status  as  'fallback' 
experts,  their  prospective  workload  is  unpredictable.  Owing  to  their  centrality  in  the  TACC  mission 
processing  path,  their  workload  (however  daunting  on  any  given  day)  is  both  unavoidable  and  top- 
priority.  Owing  to  the  fact  that  many  of  the  factors  they  must  evaluate  are  dynamic  and  outside  the 
scope  of  both  their  ken  and  their  control,  they  are  often  forced  to  operate  in  a  sort  of  reactive  mode. 
These  general  points  contribute  to  a  picture  of  the  flight  planners'  role  as  being  susceptible  to  stress  and 
burnout. 


Progressive  Shift  toward  Coordinated  Look-Ahead 

In  our  first  Phase  II  KA  visit  focusing  on  flight  planning  (December  2002),  we  were  advised  that  the 
flight  planning  shop  had  recently  succeeded  in  changing  its  mode  of  operations  with  regard  to 
timeframes  and  situation  awareness  over  its  workstream.  In  the  past,  once  flight  plans  were  generated 
they  were  not  revisited  until  and  unless  some  exception  arose.  By  the  time  of  the  December  2002  visit, 
it  was  stated  that  the  flight  planners  were  now  conducting  proactive  reviews  of  pending  flights  /  flight 
plans  up  to  4  days  in  advance  of  launch.14 

Comments  and  Analysis: 

This  migration  to  a  more  proactive  review  is  a  good  thing,  to  be  sure.  It  indicates  recognition  of  the  fact 
that  organized  look-ahead  can  catch  and  resolve  problems  before  they  become  intractable.  It’s  also 
important  to  note  that  this  development  mirrors  concerns  about  doing  a  preliminary  /  prospective  'scrub' 
of  pending  missions  /  flights  that  were  consistently  expressed  by  SME’s  we  interviewed  from  the 
Execution  Cell.15  It  appears  that  the  flight  planning  shop's  move  to  institute  such  a  proactive  review  was 
done  independently  of  any  action  on  the  part  of  other  relevant  units.  It  also  appears  that  there  is  a 
coalescing  consensus  in  TACC  to  the  effect  that  some  form  of  proactive  review  is  needed  in  the  hours 
leading  up  to  mission  launch. 


,4  Source:  KA  visit  to  XOCZ,  December  2002. 

15  Source:  KA  with  Execution  Cell  staff,  October  /  November  2003. 
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Relationship  between  Flight  Planning  and  the  Emergent  IFM  Process 

In  theory,  the  move  toward  integrated  flight  management  (IFM)  and  the  arrival  of  dispatcher-style  flight 
managers  (FM's)  can  and  will  reduce  the  load  on  the  traditional  flight  planning  shop.  The  IFM  concept 
is  still  in  the  process  of  being  implemented  over  3  years  after  being  introduced.  As  of  Phase  II,  it  was 
still  the  case  that  the  vast  majority  of  TACC  missions  were  being  handled  via  the  traditional  means.  As 
of  December  2002,  it  was  claimed  that  the  IFM  process  accounted  for  no  more  than  8%  of  the  entire 
TACC  mission  throughput.16  The  figure  given  us  by  flight  manager  SME's  in  June  2003  was  15  -  20% 
of  all  missions.17  Though  substantially  higher  than  the  estimate  given  by  the  flight  planner  SME,  this 
figure  is  still  a  minority  of  overall  TACC  mission  throughput. 

Although  the  new  cadre  of  FM's  is  trained  to  generate  and  refine  flight  plans  just  as  the  traditional  flight 
planners  do,  the  flight  planning  shop  still  attempts  to  'pre-process'  IFM  missions  in  the  sense  of 
generating  initial  ACFP  specifications  to  be  stored  for  subsequent  FM  review  and  usage.  This  gives  the 
FM  something  to  work  with  when  he  /  she  gets  started  on  a  'paper  the  crew'  task,  typically  4  to  6  hours 
prior  to  mission  launch.  According  to  comments  made  during  our  December  2002  KA  visit,  it  would 
appear  the  FM's  commonly  end  up  re-running  the  flight  plans  during  this  later  work. 18 

Comments  and  Analysis: 

It  is  not  surprising  that  the  flight  planning  shop  remains  engaged  in  the  minority  workstream  destined  for 
FM  processing.  TACC  is,  after  all,  still  in  the  midst  of  its  long  ramp-up  into  the  new  IFM  way  of  doing 
things.  However,  there  remain  two  general  issues  that  may  bear  further  scrutiny  in  evaluating  whether 
or  not  the  current  interplay  of  flight  planners  and  flight  managers  is  working  as  well  as  it  can. 

The  first  issue  concerns  the  training  and  capabilities  of  the  FM's  with  respect  to  the  flight  planning 
function.  Although  the  FM's  are  trained  to  use  ACFP  (which  they  access  via  the  Local  User  Interface 
(LUI)),  they  may  still  lack  the  depth  of  expertise  the  flight  planners  have.  In  our  December  2002  KA 
visit  to  XOCZ,  there  were  multiple  SME  points  indicating  that  facility  with  ACFP  requires  significant 
experience.  Examples  of  such  points  included: 

•  The  fact  that  XOCZ  continues  to  consider  'pre-processing'  of  IFM  missions  an  active  part  of  their 
workstream 

•  Multiple  allusions  to  XOCZ  serving  as  the  backup  /  fallback  source  of  flight  planning  expertise 
available  to  the  FM  staff 

•  Multiple  statements  to  the  effect  that  expertise  with  ACFP  is  a  key  factor  in  the  quality  and 
efficiency  of  flight  planning19 


10  Source:  KA  visit  to  XOCZ,  December  2002. 

17  Source:  Roth  (2003,  July) 

18  Source:  KA  visit  to  XOCZ,  December  2002. 

17  For  example,  there  was  a  statement  made  in  our  December  2002  visit  to  XOCZ  to  the  effect  that  ACFP  could  be  'junk'  if 
you  didn't  know  how  to  use  it. 
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•  Allusions  to  the  level  of  expertise  needed  to  identify  the  1  or  2  truly  feasible  routing  specifications 
out  of  potentially  hundreds  (or,  in  some  cases,  thousands)  ACFP  is  capable  of  generating 

•  Allusions  to  the  effect  that  ACFP  can  be  a  cryptic  application  whose  use  requires  recourse  to  tech 
support20 


It  comes  as  no  surprise  that  (as  a  class)  the  flight  planners  are  better  able  to  use  ACFP  (and,  by 
extension,  to  produce  effective  flight  plans)  than  the  FM's.  By  the  same  token,  one  might  well  question 
the  extent  to  which  the  current  situation  provides  FM's  with  sufficient  in-depth  ACFP  usage  to  allow 
them  to  rise  to  the  flight  planners'  relative  level  of  such  expertise.  The  current  pre-processing  of  IFM 
missions  by  the  flight  planners  constitutes  only  a  portion  of  their  workload.  Assuming  the  TACC 
workstream  shifts  toward  the  IFM  model  as  planned,  any  deficiencies  in  FM  expertise  will  become  more 
problematical  as  this  shift  proceeds. 

The  second  issue  concerns  the  viability  of  the  flight  plans  the  flight  planners  generate  and  store  for 
subsequent  use  by  the  FM's.  An  FM  typically  begins  his  /  her  'paper  the  crew'  activities  around  4-6 
hours  before  mission  launch.  It  is  typical  for  a  flight-planner-generated  flight  plan  to  be  10  or  more 
hours  old  at  this  point  in  time.21  As  a  result,  FM's  frequently  (and,  according  to  some  -  typically)  re-run 
flight  plans  (via  ACFP)  during  their  pre-launch  work. 

It  should  also  be  pointed  out  that  the  typical  accretion  time  of  a  flight  plan  generated  by  a  flight  planner 
is  too  soon  to  have  reasonably  been  informed  by  the  WX  shop's  forecast  charts  (whose  predictions 
extend  about  6  hours  into  the  future).  This  means  that  the  emergence  of  problematical  weather 
conditions  could  easily  make  a  flight  planner's  product  obsolete,  thus  forcing  the  (presumably  lesser- 
experienced)  FM  to  have  to  back  up  and  start  the  flight  planning  from  scratch.  Naturally,  there's  little 
that  can  be  done  to  assure  that  the  flight  planner's  first  cut  is  necessarily  feasible  as  far  as  weather  is 
concerned.  Instead,  the  point  is  that  pop-up  WX  problems  can  force  a  'crunch  situation'  in  which  the 
personnel  having  to  react  (the  FM's)  are  not  the  personnel  best  equipped  to  do  rapid  re-planning. 


Flight  Planning  Work  as  a  Two-Stage  Process 

The  flight  planning  shop's  work  can  be  seen  as  breaking  down  into  two  distinct  phases  or  stages.  The 
first  is  the  generation  of  initial  (ATC-submittable)  route  specifications  based  on  ACFP.  The  second  is 
the  editing  and  re-planning  done  in  light  of  ATC  feedback  or  even  rejections.  This  second  stage  can 
extend  into  multiple  submit  /  revise  cycles.22 


20  At  one  point  early  in  our  December  2002  visit,  a  SMb  noted  that  'even  I  o-year  veterans'  must  sometimes  tall  back  to 
contractor  tech  support  to  figure  out  what  ACFP  is  doing  and  why  it's  producing  the  results  it  does. 

21  In  our  December  2002  XOCZ  visit,  the  age  of  a  flight  planner's  product  at  the  point  an  FM  takes  it  up  was  stated  to  be  in 
the  10  to  14  hour  range. 

22  Source:  KA  visit  to  XOCZ,  December  2002. 
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Comments  and  Analysis: 


Although  both  these  flight  planning  task  phases  can  take  arbitrary  lengths  of  time,  it  is  the  second  (ATC 
submit  /  revise)  that  is  most  'open-ended'  and  hence  unpredictable.  For  one  thing,  there's  no  sure  way  to 
predict  whether  ATC  will  approve  a  given  plan.  For  another  thing,  the  decision  space  is  so  vast  and 
dynamic  (e.g.,  via  NOT  AM's)  that  there's  no  stable  basis  for  even  guesstimating  the  odds  for  approval  of 
any  given  plan  on  any  given  day.  This  second  stage  is  also  the  one  that  is  more  potentially  time-critical. 
Owing  to  its  coming  after  the  ACFP  generation  stage,  it's  conducted  closer  to  deadline.  Owing  to  its 
termination  criterion  being  external  to  TACC  (i.e.,  in  the  form  of  eventual  ATC  approval),  this  is  the 
stage  more  likely  to  leave  planners  (and  other  TACC  staffers)  'in  the  dark'  while  launch  time  approaches. 

There  are,  of  course,  no  interventions  within  TACC  which  would  directly  influence  the  rapidity  or 
leniency  of  ATC  decisions.  Phrased  another  way,  TACC's  flight  planning  staff  will  always  be 
vulnerable  to  being  'jerked  around'  whenever  ATC  decides  a  given  flight  plan  is  unacceptable  or 
unfeasible.  This  means  the  most  probably  constructive  approach  to  WCSS  intervention  would 
emphasize  means  for  facilitating  more  efficient  re-planning  as  the  need  for  such  re-planning  occurs. 


Flight  Planners'  Reliance  on  Locally-Accreted  and  Locally-Maintained  F2  Database 

One  of  the  most  striking  aspects  of  current  flight  planning  operations  is  the  fact  that  the  flight  planning 
shop  relies  very  heavily  on  the  F2  Database  -  a  critical  data  resource  whose  contents  are  generated, 
accreted,  and  maintained  locally  within  the  flight  planning  shop  itself.  To  be  sure,  other  'shops'  or  units 
within  TACC  rely  just  as  heavily  on  various  data  assets.  However,  there  is  no  other  such  unit  for  whom 
the  stewardship  of  such  a  critical  data  resource  is  a  task  assigned  to  the  unit  itself.  It  is  an  indication  of 
the  complexity  of  the  flight  planning  decision  space  that  such  a  resource  is  necessary.  It  is  an  indication 
of  the  criticality  of  the  flight  planning  function  to  overall  TACC  operations  that  such  a  resource  was 
established.  It  is  an  indication  of  the  relatively  high  degree  and  depth  of  'expertise'  associated  with  the 
flight  planning  task  that  this  resource  is  as  voluminous  as  it  is.23 

Comments  and  Analysis: 

The  combination  of  decision  data  complexity  and  procedural  reliance  make  the  F2  Database  (and  /  or 
some  equivalent  routing  knowledge  repository)  a  critical  resource  for  the  flight  planners.  Any 
innovations  undertaken  in  support  of  flight  planning  must  account  for  the  contents  and  utility  of  the  F2 
Database.  This  does  not  mean  that  the  current  form  and  capabilities  of  the  existing  F2  Database  must 
circumscribe  the  extent  of  future  routing  knowledge  support.  We  identified  one  particular  way  in  which 
the  current  F2  Database  could  be  extended  or  improved  to  better  support  flight  planners.  This  is  the 
topic  of  the  next  subsection. 


23  During  our  December  2002  KA  visit  to  XOC  we  were  told  that  approximately  6500  route  records  are  stored  in  the  F2 
Database. 
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Limitations  in  Employing  the  F2  Database 

The  importance  of  the  F2  Database  to  the  flight  planning  process  contrasts  with  the  relatively  narrow 
way  it  must  be  employed.  The  records  are  indexed  via  'city-pairs'  -  dyads  specifying  the  arrival  and 
departure  ports  defining  the  prospective  flight's  end  points.  Users  must  index  and  search  the  records 
solely  on  the  basis  of  these  city-pairs.  This  means  that  an  F2  query  may  produce  several  different  route 
specifications  for  getting  from  departure  port  A  to  arrival  port  B.  Once  a  route  specification  is  chosen 
for  refinement  into  a  flight  plan  for  a  given  mission,  the  flight  planner  must  manually  edit  it  as  a  text 
document. 

The  primary  inefficiency  in  the  current  F2  arrangement  relates  to  the  structure  of  the  route  specifications 
stored  therein.  They  are  essentially  'all  or  nothing'  records  of  entire  routes  linking  city-pairs.  They 
cannot  be  readily  decomposed  and  edited  in  terms  of  their  subsidiary  route  segments.  Neither  can  the 
users  index  into  the  F2  Database  on  the  basis  of  a  particular  such  segment.  This  means  that  obtaining  a 
precedent  specification  for  a  given  segment  of  an  overall  route  requires  laboriously  scanning  through  an 
arbitrary  number  of  complete  end-to-end  route  specifications.  This  makes  tweaking  an  existing  flight 
plan  (e.g.,  during  last-minute  replanning)  more  labor  intensive  and  inefficient  than  it  might  be.  In 
addition,  this  all-or-nothing  characteristic  of  the  current  record  structure  induces  a  requirement  that  all 
records  be  evaluated  and  accreted  to  the  database  as  non-decomposable  wholes.  This  makes  for 
considerable  redundancies  among  stored  route  specifications  (i.e.,  they  vary  only  marginally  by 
differences  among  features  of  particular  segments  or  sets  of  segments). 

Comments  and  Analysis: 

The  redundant  'all-or-nothing'  F2  Database  records  induce  considerable  overhead  for  searching, 
manipulating,  and  maintaining  this  critical  flight  planning  resource.  This  excessive  overhead  has 
numerous  aspects  and  corresponding  deleterious  effects  such  as: 

•  Increasing  nominal  search  time  to  locate  a  viable  candidate  route  specification 

•  Increasing  the  minimum  amount  of  text  that  must  be  scanned  to  assess  viability  of  any  given 
candidate  record 

•  Increasing  the  time  required  to  review,  compare,  and  select  among  route  specifications  returned  on  a 
given  query 

•  Increasing  the  amount  of  text  that  a  planner  must  contend  with  to  make  a  change  at  any  level  of 
granularity 

•  Increasing  the  cognitive  burden  on  the  person  searching  the  database  and  reviewing  the  records 
returned 

•  Increasing  the  risk  of  decision  errors  in  evaluating,  comparing,  and  selecting  among  the  candidate 
route  specifications 


36 


•  Increasing  the  number  of  records  that  must  be  reviewed  for  modification  with  each  DAFIF  update 
cycle  (every  28  days) 

•  Increasing  the  risk  of  errors  in  evaluating  which  and  how  many  records  need  to  be  updated  with  each 
DAFIF  cycle 

•  Increasing  the  cognitive  and  procedural  burdens  for  determining  which  route  specifications  may 
reasonably  be  retained  and  which  may  be  deleted 


In  light  of  these  factors,  the  GAMAT  team  proposed  the  introduction  of  a  'two-level'  or  'double-level' 
capability  into  the  next-generation  F2  Database  (or  its  equivalent).  The  two  'levels'  connote  that  there 
should  be  two  levels  of  route  granularity  at  which  flight  planners  could  index,  address,  and  manipulate 
route  specifications.  The  first  would  be  an  overall  route  linking  a  city-pair  (as  is  currently 
implemented).  The  second  would  be  a  finer-grained  level  at  which  subsidiary  pieces  ('segments')  of  this 
overall  route  could  be  indexed,  addressed,  and  manipulated. 

We  had  conceptualized  such  a  bi-level  approach  to  route  specifications  as  a  result  of  our  early  GAMAT 
Phase  II  KA  visits  to  TACC.  We  noted  that  whenever  a  complete  'canned'  route  specification  did  not  fit 
a  planner's  current  purposes,  he  /  she  would  modify  the  segment(s)  of  that  routing  spec  necessary  to 
transform  it  into  one  better  suited  for  the  current  mission  or  circumstances.  In  addition,  there  were  SME 
allusions  to  key  pieces  of  rationale  for  a  given  routing  spec  being  predicated  not  on  the  entire  route,  but 
also  upon  conditions  and  /  or  constraints  pertaining  to  a  given  route  segment.24  Beginning  with  our 
June  2003  KA  trip  to  AMC  (cf.  Roth:  2003,  July),  we  began  actively  probing  the  SME's  on  the 
prospects  and  perceived  utility  of  addressing  routes  by  segments.  The  response  was  uniformly  positive 
to  such  a  prospect.25 


Limits  to  Flight  Plan  Revisions  without  Re-Running  ACFP 

ACFP  is  the  primary  tool  for  generating  routing  specs  for  a  new  flight  plan.  The  output  from  ACFP  is  a 
textual  routing  specification  which  the  flight  planner  may  edit  or  otherwise  tweak  as  he  /  she  sees  fit. 
Once  the  flight  planner  is  satisfied  with  the  route  specification  derived  from  ACFP,  he  /  she  can 
subsequently  submit  it  to  air  traffic  control  (ATC)  for  review  and  approval.  If  ATC  doesn’t  approve  the 
routing  'as  is',  the  flight  planner  may  or  may  not  be  able  to  revise  the  current  specifications  without 
going  back  to  ACFP  and  essentially  starting  over.26 


24  Cf.  Roth  (2003,  March) 

23  For  example,  the  SME  tasked  to  oversee  and  maintain  the  existing  F2  database  proactively  suggested  that  the  ability  to 
address  routes  in  terms  of  segments  would  be  a  big  help  in  a  number  of  ways.  (cf.  Roth,  2003:  October) 

26  Source:  KA  visit  to  XOCZ,  December  2002. 
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Comments  and  Analysis: 

It's  not  clear  what  criteria  can  or  must  be  invoked  to  ascertain  whether  a  flight  plan  can  be  fixed  in  its 
current  form  versus  being  re-done  by  falling  back  to  ACFP.  The  relatively  simplistic  and  time- 
consuming  process  of  dealing  with  route  specifications  as  raw  text  makes  either  course  of  action  slower 
and  more  susceptible  to  error  than  it  should  be  or  could  be.  This  text-only  situation  necessarily  makes 
the  review  and  decision  tasks  more  cognitively  burdensome,  because  there  are  no  explicit  cues  relieving 
flight  planners  from  having  to  'connect  the  dots'  mentally. 

Based  on  observations  of  flight  planners  working  through  the  route  specification  process  beginning  with 
ACFP,  it  appeared  that  the  post-ACFP  editing  was  more  time-consuming  than  working  with  ACFP  to 
get  the  initial  routing  specs  in  the  first  place.  Add  to  this  the  necessity  of  (re-)  orienting  oneself  to  a 
pending  work  product  (the  submitted  flight  plan)  the  details  of  which  he  /  she  may  have  forgotten,  and  it 
seems  clear  that  dealing  with  an  ATC  rejection  (either  major  or  minor)  can  take  up  as  much  time  as 
generating  the  plan  that  was  originally  submitted. 

Even  more  to  the  point  is  the  fact  that  a  route  string  /  specification  is  treated  as  a  whole.  This  begins 
•  with  the  generation  of  a  routing  specification  from  ACFP,  where  the  sole  means  of  denoting  the  desired 
route  is  a  'city-pair'  (i.e.,  designations  for  the  end  points).  ACFP  then  generates  a  candidate  set  of  routes 
between  these  end  points,  each  one  of  which  is  a  unary  collection  of  text  descriptors.  This  means  that 
decisions  about  a  route's  viability  generally  have  to  be  evaluated  on  an  'all  or  nothing'  basis  (i.e.,  it's 
either  'all  good'  or  'junk').  The  only  extent  to  which  flight  planners  may  circumvent  this  all-or-nothing 
constraint  is  to  go  to  the  trouble  of  delving  into  the  textual  route  string  and  manually  edit  it  into 
something  more  viable. 

All  these  foregoing  points  could  be  made  less  problematical  if  flight  planners  were  capable  of 
addressing  route  specifications  as  sets  of  modular  subcomponents  (i.e.,  'segments'  comprising  the  entire 
route).  A  coherent  schema  for  doing  this  would  permit: 

•  Initial  ACFP  (or  equivalent)  route  specifications  capable  of  being  addressed  in  a  more  modular  (and 
hence  less  cognitively  burdensome)  manner 

•  An  ability  to  more  readily  focus  in  on  and  modify  one  or  another  route  'segment'  in  realtime 

•  The  ability  to  index  (and  hence  maintain)  the  F2  Database  (or  evolutionary  descendant)  on  a  finer- 
grained  basis  than  is  currently  possible 

•  The  ability  to  reduce  individual  record  storage  requirements  within  the  F2  Database  (or  evolutionary 
descendant)  by  eliminating  the  need  to  record  an  entire  city-to-city  route  string  for  each  and  every 
variation  on  the  potential  routing  between  those  end  points 

•  ACFP  (or  equivalent  automated)  generation  of  route  specifications  for  only  those  segments  in  need 
of  replanning  (e.g.,  in  light  of  ATC  rejections  or  other  pop-up  requirements  for  replanning) 
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Issues  with  Disparate  Features  among  ACFP  Versions 

It  was  surprising  to  learn  that  different  versions  of  ACFP  have  distinctly  different  features,  and  that 
these  differences  made  for  corresponding  differences  in  the  perceived  utility  of  one  versus  another 
version  of  the  software.  At  the  time  of  our  December  2002  KA  visit  to  XOCZ  version  2.5  was  in  use, 
and  a  version  3.0  was  expected  to  arrive  by  September  2003.  It  was  stated  that  2.5  was  the  latest  version 
to  offer  what  was  termed  'full  functionality',  and  that  version  3.0  was  already  known  to  offer  less  than 
this  level  of  functionality.  Perhaps  most  importantly,  post-2.5  versions  of  ACFP  were  stated  to  have 
dropped  the  ability  to  retrieve  and  reuse  past  planning  products. 

Comments  and  Analysis: 

Any  decrease  in  the  range  of  functionalities  provided  by  a  later  software  release  is  a  curious 
development  worthy  of  interest.  In  the  case  of  ACFP,  the  purported  loss  of  retrieval  /  reuse  capabilities 
is  especially  interesting,  insofar  as  the  flight  planning  shop  actively  attempts  to  maximize  the 
opportunities  to  operate  by  'precedent'  (i.e.,  by  calling  up  a  known  route  specification  and  editing  it  to  fit 
the  current  mission  requirements).  Furthermore,  in  the  course  of  performing  detailed  flight  planning,  the 
flight  planners  often  have  to  do  considerable  'what  if  examination  of  options  and  alternatives.28  In  a 
decision  space  as  large  and  multi-faceted  as  flight  planning,  the  number  of  options  available  for  review 
is  a  positive  aid  in  managing  complexity. 


Issues  with  Availability  of  Relevant  Information  during  Flight  Planning 

Flight  planning  would  be  more  effective  if  the  initial  routing  specifications  remained  viable  through  to 
the  point  of  mission  launch.  Given  the  number  of  things  which  can  'clobber'  a  flight  plan,  this  naturally 
must  remain  an  ideal  instead  of  a  practical  goal.  Most  of  the  factors  which  can  invalidate  an  initial  flight 
plan  are  not  fixed  by  the  point  in  time  when  the  flight  planner  generates  his  /  her  'first  cut’.  To  some 
extent,  however,  the  attendant  risks  can  be  attributed  to  non-availability  of  relevant  information  at  that 
same  point  in  time.  In  the  following  subsections  we  shall  briefly  note  some  of  the  information-specific 
factors  which  contribute  to  the  risk. 


27  Source:  KA  visit  to  XOCZ,  December  2002. 

28  Source:  KA  visit  to  XOCZ,  December  2002. 
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NOTAM's 


Notices  to  Airmen  (NOTAM's)  are  the  bulletins  issued  by  (e.g.)  airfields  advising  the  aviation 
community  of  constraints,  changes,  requirements,  news,  etc.  Although  NOTAM's  are  not  new,  there 
remains  no  efficient  means  for  checking  them.  This  means  that  flight  planners  are  hard  pressed  to  stay 
current  on  conditions  affecting  a  given  mission's  ability  to  use  a  given  location.  Flight  planners  do  not 
currently  have  an  efficient  and  effective  means  for  checking  NOTAM's  in  the  course  of  their  planning 
tasks.  As  a  result,  it  is  all  too  easy  for  them  to  unknowingly  generate  a  flight  plan  destined  for  re¬ 
planning  owing  to  conditions  of  which  they  were  unaware.  29 

Weather  (WX)  Information 

Given  the  advance  timeframe  in  which  conventional  flight  planning  is  conducted,  there  is  little  chance 
that  accurate  fine-grained  WX  forecasts  can  be  made  available  for  flight  planners'  reference.  The  typical 
timeframe  for  flight  planning  is  10+  hours  prior  to  mission  launch.  This  exceeds  the  nominal  6  hours' 
forecast  horizon  for  the  WX  shop's  most  detailed  charts.30 

Diplomatic  Clearances  (DIP's) 

Any  flight  passing  over  other  nations  has  to  have  been  granted  diplomatic  clearance  (DIP)  by  the  given 
nation(s).  The  flight  planning  shop  is  involved  with  DIP's  only  to  the  extent  of  requesting  clearances  on 
flights  for  which  (a)  this  has  not  yet  been  done  or  (b)  changes  in  circumstances  require  re-examination 
of  clearance  issues  and  /  or  viability.  The  flight  planner  has  no  automated  support  in  maintaining 
situation  awareness  on  the  viability  of  DIP's.  As  a  result,  changes  in  DIP  status  may  invalidate  his  /  her 
plans  (or  plan  options)  without  him  /  her  even  knowing  about  it. 

Furthermore,  it  falls  upon  the  flight  planner  to  identify  situations  (particularly  during  re-planning)  where 
changes  in  the  routing  or  predicted  flight  scheduling  may  need  to  be  referred  to  the  DIP  shop  to  see  if 
and  how  they  affect  DIP's  and  /or  DIP  requirements.  This  mission-critical  /  time-critical  requirement  for 
reviewing  and  re-evaluating  DIP's  is  not  a  minor  incidental  occurrence.  A  senior  DIP  Shop  SME 
claimed  that  it  is  typical  for  the  DIP  staff  to  have  to  see  and  review  a  mission  up  to  4  or  5  times  as 
changes  occur  prior  to  execution.31 

Comments  and  Analysis: 

The  flight  planner’s  job  is  made  more  difficult  and  error-prone  to  the  extent  that  relevant  circumstances 
are  unknown  to  him  /  her  and  hence  not  taken  into  account.  The  three  primary  examples  of  such  key 
information  (NOTAM’s,  weather,  and  DIP’s)  all  represent  factors  which: 

•  Can  invalidate  an  otherwise-viable  flight  plan 


29  Separate  USAF  and  FAA  projects  have  been  undertaken  with  the  objectives  of  centralizing  access  to  known  NOTAM's, 
affording  global  access  to  this  compiled  data,  and  even  providing  timely  alerting  on  newly-accreted  NOT AM  information. 

30  The  WX  shop  'chartmaker'  also  generates  charts  tor  longer  timeframes,  but  these  are  progressively  less  Ime-gramed  and 
less  reliable.  The  'second-tier'  WX  shop  charts  are  supposed  to  be  framed  up  to  10  -  12  hours  into  the  future.  This  is  little 
help  to  the  flight  planners,  who  are  doing  their  planning  at  about  the  time  when  these  'secondary'  and  less-reliable  charts  are 
fresh. 

31  Source:  Roth  (2003,  March) 
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•  Can  cause  such  invalidation  at  any  time  prior  to,  during,  or  following  the  flight  planner's  work  on  the 
given  mission 

•  Cannot  be  directly  changed  on  the  flight  planner's  own  initiative 

•  Cannot  be  directly  changed  on  TACC's  own  initiative 

•  May  cost  arbitrary  amounts  of  time  to  resolve,  and  hence. . . 

•  May  force  last-minute  cancellation  /  postponement  of  a  given  mission 


Naturally,  there's  no  way  to  guarantee  that  these  factors  and  their  attendant  risks  can  be  completely 
eliminated  as  sources  of  planning  risk.  However,  there  is  plenty  of  room  for  improvement  in  keeping 
the  flight  planners  apprised  of  these  factors  (vis  a  vis  a  given  mission)  such  that: 

•  Time  is  not  wasted  planning  a  flight  that  simply  can't  be  done 

•  Time  is  not  lost  learning  of  changes  which  require  re-planning 

•  Mission  constraints  are  known  (within  reason)  at  the  time  the  flight  planner  is  expected  to  produce  a 
viable  flight  plan 


Of  these  three  categories,  the  one  examined  more  closely  for  WCSS  support  within  the  Phase  II 
GAMAT  effort  was  DIP'S.  This  focus  was  not  intended  to  indicate  we  had  concluded  DIP  problems  are 
absolutely  more  important  or  more  critical  than  those  relating  to  weather  and  /  or  NOTAM's.  The 
emergence  of  unforeseen  constraints  in  any  one  of  these  categories  can  be  inimical,  or  even  'fatal',  to  a 
flight  plan's  viability.  All  three  are  Tiigh  risk'  for  the  occurrence  of  such  unexpected  constraints,  because 
all  three  pertain  to  factors  which  are  beyond  the  control  or  precise  prediction  of  TACC  itself. 

Still,  the  DIP  category  recommended  itself  for  further  examination  based  on  two  factors.  First, 
improved  situation  awareness  (SA)  regarding  both  weather  and  NOTAM’s  had  become  the  objects  of  IT 
innovation  projects  in  recent  times.  Our  own  WCSS-GWM  had  demonstrably  addressed  the  weather 
category,  and  a  parallel  R&D  effort  in  Phase  II  was  similarly  addressing  NOTAM's.  Efforts  to  do  the 
same  in  the  realm  of  DIP'S  consisted  of  the  recently-arrived  Logbook  capability  and  BBN's  development 
of  a  'lead  time  calculator'  in  a  parallel  project  during  Phase  II.  Both  these  initiatives  represent 
innovations  intended  to  improve  DIP  processing  capabilities.  Neither,  however,  necessarily  improves 
situation  awareness  for  flight  planners  on  DIP  status  during  the  critical  period  when  mission  launch  is 
imminent. 
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Second,  it  must  be  pointed  out  that  the  context  for  DIP  processing  has  certain  characteristics  making  it 
arguably  even  more  constrained  a  decision  space  than  is  the  case  for  weather  or  NOT  AM's.  The  factors 
underlying  this  claim  are  summarized  in  Table  1.4-1.  As  illustrated  in  Table  1.4-1,  it  is  reasonable  to 
claim  that  both  (a)  the  practical  planning  horizon  for  DIP's  is  longer  than  for  either  WX  or  NOTAM's, 
and  (b)  the  potential  impact  on  a  flight  plan  (in  terms  of  area  /  distance  required  for  correction)  is 
greater.  In  other  words,  DIP's  is  'higher-risk'  in  terms  of  both  deadlines  for  'getting  it  right'  and  the  cost 
of  adapting  to  a  change  at  the  last  minute. 


Table  1.4-1:  Comparative  Problematicity  in  WX,  NOTAM's,  and  DIP's 


ISSUE 

RE:  Weather 

RE:  NOTAM's 

RE:  DIP'S 

Deadline  for 
Planning 
Changes 

•  None  -  WX  issues 
can  pop  up  any  time 

•None  -  NOTAM's  can  be 
issued  at  any  time 

•  T-24h  (minimum 
lead  time  for  DIP 
request) 

Look-Ahead 

Horizon 

•  0  -  24  hours  into  the 
future  (general) 

•  0  -  circa  8  hours  into 
the  future  (specific) 

•  0-24  hours  into  the 
future 

•  24+  hours  into  the 
future 

Scope  of  Negative 
Impact 
(Geospatial) 

•  Airfield  /  Location 
(minimum) 

•  Sub-National  Area  / 
Region  (maximum) 

•  Airfield  /  Location 
(typically) 

•  Sub-National  Area  / 

Region  (conceivably) 

•  Entire  nation 

Risk:  Divert 
Distance 

•  10's  -  100's  of  miles 
(to  avoid  bad  WX;  to 
access  airfield) 

•  10's  -  100's  of  miles  (to 
feasible  airfield) 

•  100’s  -  1000’s  of 
miles  (to  avoid 
entire  country) 

This  relative  risk  is  compounded  by  the  fact  that  the  DIP  Shop  may  have  to  review  a  given  mission  up  to 
4  or  5  times  by  the  time  it  is  accomplished.32  DIP  workloads  are  such  that  the  rate  of  errors  (DIP 
clearance  violations)  is  claimed  to  run  approximately  1%.33  The  incidence  of  missions  cancelled  or 
turned  back  on  account  of  DIP  violations  was  stated  to  be  on  the  order  of  approximately  0.2%. 34 

Time  and  gain  during  our  Phase  II  KA  visits  we  received  allusions  to  the  fact  that  DIP  clearances 
constitute  not  just  a  significant  constraint  on  the  general  mission  /  flight  planning  decision  making 
process  but  also  a  very  problematical  constraint  on  T ACC's  ability  to  dynamically  re-plan  missions  and 
flights  as  execution  time  drew  nigh.  As  a  result,  we  elected  to  include  some  means  for  providing 
situation  awareness  on  DIP  status  and  viability  to  TACC  staffers  in  both  the  planning  and  execution 
phases  of  the  mission  operations  process  path. 


32  Source:  Roth  (2003,  March). 

33  In  the  March  2003  KA  interviews  with  DIP  SME's,  it  was  stated  that  typically  3  to  5  out  of  the  500  missions  being 
processed  on  a  given  day  will  have  dip  violations.  (Roth:  2003,  March) 

4  These  incidence  figures  are  drawn  from  Koth  (2003,  March).  These  relative  incidence  figures  don'i  seem  like  much  in 
relation  to  the  overall  workflow  (up  to  500  missions  per  day).  However,  it  must  always  be  borne  in  mind  that  even  a  single 
mission  cancellation  represents  tens,  and  perhaps  even  hundreds,  of  thousands  of  dollars  lost  in  mission  costs.  Add  to  this  the 
prospect  of  generating  ’cascading'  failures  as  one  failed  mission  negatively  impacts  parallel  /  subsequent  missions,  and  this 
cost  escalates  dramatically. 
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Workload  Associated  with  Generating  Notional  Flight  Plans 

As  noted  in  the  chapter  on  collaboration  issues,  the  flight  planner  is  responsible  for  the  generation  of 
'notional'  flight  plans  early  in  the  overall  mission  /  flight  planning  process.  This  is  done  to  create  'initial 
sketches'  of  prospective  routes  so  that  mission  planners  can  evaluate  options,  constraints,  and 
possibilities  for  a  new  mission  they  are  trying  to  plan.35  A  notional  flight  plan  also  provides  the  mission 
planners  with  the  ability  to  specify  those  nations  for  which  DIP  clearances  must  be  obtained.  This 
enables  the  DIP  shop  to  get  a  head  start  on  the  time-consuming  task  of  arranging  the  DIP  clearances  for 
the  new  mission.  Furthermore,  the  DIP  shop  may  request  a  flight  plan  specification  to  aid  them  in 
determining  DIP  prospects  and  constraints. 36  These  DIP  Shop-requested  plans  are  expected  to  be  more 
akin  to  final  flight  plans  (i.e.,  more  details  on  routing  and  prospective  scheduling)  than  the  'notional' 
ones  requested  by  the  mission  planners.  The  estimated  incidence  of  DIP  Shop  requests  for  flight  plans  is 
approximately  20%  of  the  missions  being  processed  by  the  DIP  Shop.37 

The  general  layout  of  the  notional  flight  planning  process  is  illustrated  in  Figure  1.4-1.  By  and  large,  the 
mission  planners'  requests  for  notional  flight  plans  will  come  far  in  advance  of  the  timeframe  during 
which  the  flight  planners  are  typically  doing  their  detailed  flight  planning  on  a  given  mission.  This 
'advance'  status  pretty  much  applies  to  the  DIP  Shop  requests  as  well.  Even  when  the  DIP  clearance 
process  is  undertaken  relatively  late  in  the  mission  process  path,  it  will  predate  the  flight  planner's  final  / 
detailed  flight  planning  work.  Because  the  DIP  shop  needs  to  be  processing  DIP  requests  1  or  more 
days  ahead  of  mission  launch,  this  work  must  be  initiated  prior  to  the  flight  planners'  nominal  timeframe 
for  final  detailed  flight  planning  (which  can  run  as  little  as  10  -  12  hours  prior  to  launch). 


35  It  is  not  the  case  that  mission  planners  request  a  notional  flight  plan  for  all  pending  missions.  According  to  information 
given  us  in  interviews  with  mission  planners,  they  first  attempt  to  estimate  flight  time,  etc.,  using  historical  data  assets  (e.g., 
TACC  Fly  Time  Viewer,  CAMPS  historical  data.  Great  Circle  Mapper).  However,  these  historical  data  assets  are  not 
uniformly  applicable,  accurate,  or  up  to  date.  (cf.  Roth:  2003,  July) 

36  Both  the  mission  planners  and  the  DIP  planners  may  request  a  flight  plan  from  the  flight  planning  shop.  However,  it  is 
only  in  the  case  of  the  mission  planners  (who  are  attempting  to  ascertain  a  workable  route)  that  the  product  generated  is 
termed  'notional'.  Regardless  of  how  tentative  it  may  be,  a  plan  product  generated  in  response  to  a  DIP  shop  request  is 
termed  a  'flight  plan'  (i.e.,  not  a  'notional  flight  plan'),  (cf.  Roth,  2003,  October).  This  difference  in  terminology  is  more 
than  skin-deep.  1  he  DIP  planner  needs  sufficiently  detailed  Information  on  prospective  scheduling  and  routing  (as  it  pci  tains 
to  entry  and  exit  points)  to  be  able  to  effectively  take  action  to  obtain  the  necessary  DIP  clearances,  (cf.  Roth,  2003,  March) 
Nonetheless,  our  notion  of  allowing  planners  other  than  flight  planners  to  generate  'notional'  flight  plans  has  been  pursued 
with  respect  to  affording  this  capability  to  both  mission  planners  and  DIP  planners. 

37  Source:  Roth  (2003:  July) 
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Figure  1.4-1 :  Conventional  Workflow  for  Notional  Flight  Planning 

Comments  and  Analysis: 

The  responsibility  for  generating  notional  flight  plans  naturally  adds  to  the  flight  planner's  workload.  In 
the  best  case,  notional  flight  planning  represents  an  initial  run-through  for  a  route  specification  the  flight 
planner  will  refine  at  a  later  date.  In  the  worst  case,  it's  a  workload  completely  'above  and  beyond'  the 
workstream  with  which  the  flight  planner  will  contend  for  final  /  detailed  planning  purposes.  Such 
'above  and  beyond'  cases  include  those  in  which  the  flight  planner  has  to  generate  a  plan  he  /  she  may 
never  see  again.  Circumstances  in  which  this  can  happen  include: 

•  Notional  flight  plans  generated  for  mission  planner  review,  only  to  be  discarded  as  candidates  from 
the  initial  mission  planning 

•  Notional  flight  plans  generated  as  entirely  new  options  for  a  mission  which  is  being  re-planned 
upstream  of  the  flight  planning  shop 

•  Notional  flight  plans  contributing  to  missions  on  which  the  flight  planning  shop  may  have  no 
subsequent  involvement 


During  our  Phase  II  GAMAT  work,  we  came  to  question  whether  or  not  these  notional  flight  plans 
demanded  a  level  of  detail  and  discrimination  warranting  the  personal  involvement  of  the  flight  planner 
in  each  and  every  case.  Our  inclination  was  to  configure  a  WCSS  capability  (analogous  to  the 
capabilities  being  designed  for  the  flight  planners  themselves)  that  would  permit  the  mission  planners  to 
generate  their  own  notional  flight  plans  (at  least  for  'easy'  or  'straightforward'  cases).  We  made  a  point 
to  probe  our  subject  matter  experts  on  this  prospect  during  our  October  and  November  KA  visits  to 
AMC  /  TACC.  The  responses  wo  received  (cf.,  e.g.,  Roth:  2003,  October;  2003,  November)  were  as 
follows: 

•  Representatives  of  the  flight  planning  shop  uniformly  expressed  approval  of  this  idea  in  general 
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•  The  SME's  uniformly  noted  the  utility  of  such  a  capability  in  allowing  mission  planners  to  designate 
countries  to  be  overflown,  and  hence  better  advise  the  DIP  shop  what  clearances  would  be  required. 

•  Owing  to  the  fact  that  the  majority  of  mission  routes  were  'standard'  (or  at  least  well-known)  even 
offering  this  capability  for  such  pro  forma  routes  would  have  a  significant  effect  on  reducing  flight 
planner  workload. 

•  Some  of  the  support  information  for  offloading  notional  flight  planning  has  already  been  made 
available.  The  F2  Database  data  is  accessible  outside  the  flight  planning  shop  via  a  Website,  and 
some  outside  the  flight  planning  shop  (e.g.,  the  FM's)  can  access  ACFP  via  their  Local  User 
Interface  (LUI). 

•  By  the  same  token,  the  selection  of  routes  and  route  details  can  be  contingent  on  a  variety  of  factors 
which  are  either  subtle  or  subject  to  dynamic  changes.  It  is  not  reasonable  to  assume  that  the  other 
units  given  access  to  notional  plan  generation  would  or  should  be  expected  to  know  and  /  or  keep 
track  of  such  things. 

•  All  flight  planning  shop  representatives  cautioned  that  some  measure  of  caution  would  have  to  be 
recognized  so  as  to  make  these  other  staffers'  notional  flight  plans  'dummy-proof. 


These  last  two  points  raise  a  cause  for  additional  concern  and  consideration  in  assessing  the  prospects 
for  alleviating  the  flight  planners'  notional  flight  planning  workload.  There  is  an  important  composite 
tradeoff  that  needs  to  be  evaluated.  On  the  one  hand,  it  is  fairly  clear  that  having  mission  planners 
generate  their  own  notional  flight  plans  might  aid  TACC  team  efficiency  by: 

•  reducing  time  flight  planners  must  divert  to  notional  flight  planning 

•  reducing  time  lost  to  communications,  tracking,  and  follow-up  overhead  related  to  the  request 
transactions  (between  mission  planners  and  flight  planners)  themselves 

•  reducing  the  total  time  a  mission  planner  has  to  wait  from  starting  his  /  her  mission  planning  to 
requesting  DIP  clearances 

•  promoting  somewhat  more  'lead  time'  for  the  DIP  shop  to  receive  and  begin  processing  a  mission’s 
DIP  requirements 


On  the  other  hand,  it  is  conceivable  that  such  a  capability  could  actually  degrade  TACC  team 
effectiveness  and  efficiency  if  it  led  to: 

•  diminished  quality  in  the  notional  flight  plans  generated  (relative  to  subtle  decisions  currently  made 
hy  the  flight  planner."?) 

•  increased  time  taken  by  the  mission  planners  (relative  to  the  flight  planners)  in  figuring  out  and 
deciding  the  notional  flight  plan  parameters 
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•  an  increased  number  of  questions  or  requests  for  information  raised  by  the  DIP  shop  in  response  to 
mission  planners'  notional  flight  plans3^ 

•  a  higher  number  of  substantial  're-plans'  the  flight  planners  have  to  do  at  their  downstream  detailed 
planning  stage 

•  a  higher  number  of  planning  failures  (forcing  mission  cancellations  or  delays)  owing  to  more 
numerous  such  're-plans'  at  that  late  point  in  the  process  path 

In  the  final  analysis,  we  elected  to  proceed  with  the  concept  of  affording  mission  planners  the  ability  to 

generate  and  assess  their  own  notional  flight  plans.  The  mitigating  factors  which  overrode  the 

cautionary  factors  cited  above  included: 

•  the  fact  that  the  WCSS  concepts  needed  to  support  the  mission  planners  (on  notional  flight  planning) 
were  not  categorically  distinct  from  the  concepts  we  proposed  to  generate  to  support  all  planners 

•  these  more  general  WCSS  concepts  were  not  being  constrained  or  unduly  modified  to  suit  the 
particular  purposes  of  mission  planners  doing  notional  flight  plans 

•  these  more  general  WCSS  concepts  were  independently  justified  on  their  own  merits,  meaning  that 
any  eventual  negative  evaluation  of  mission  planners'  usage  for  notional  planning  would  diminish,  . 
but  not  invalidate,  those  concepts 

•  the  consensus  among  our  SME's  that  such  a  capability  could  be  an  improvement  (subject  to  the 
cautions  noted  above) 


Our  approach  was  to  facilitate  a  process  path  within  which  the  mission  planners  were  primarily 
responsible  for  generating  notional  flight  plans  through  direct  interaction  with  a  new  flight  planning 
WCSS.  This  would  equip  them  to  perform  their  mission  planning  without  having  to  interrupt  flight 
planners  for  such  a  notional  specification.  This  notional  plan  could  then  be  forwarded  to  the  DIP 
planner  with  the  mission  planner's  initial  request  to  initiate  DIP  requests.  The  general  layout  of  this 
concept  is  given  in  Figure  1.4-2. 


38  As  noted  earlier,  the  DIP  shop  treats  advance  routing  specifications  requested  of  the  flight  planning  shop  as  'flight  plans' 
rather  than  'notional  llignt  plans',  mere  is  an  insinuation  that  the  dip  shop  expects  something  more  substantial,  reliable,  and 
maybe  even  more  detailed,  than  the  mission  planners  might  routinely  expect.  In  the  event  that  DIP  Shop-requested  plans  are 
not  as  ’notional’  as  those  requested  by  the  mission  planners,  one  could  conceive  of  the  DIP  Shop  continuing  to  'ping'  the  flight 
planners  for  route  specifications  regardless  of  who  generated  the  initial  'notional'  plan.  Such  a  trend  would  at  least  partially 
negate  the  flight  planner  workload  reduction  we  are  seeking  to  induce. 
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Figure  1.4-2:  Procedural  Concept  for  New  Notional  Flight  Planning  Layout 

The  primary  innovation  is  to  provide  WCSS  support  allowing  the  mission  planners  direct  access  to  flight 
planning  tools.  This  access  could  conceivably  /  secondarily  be  made  available  to  DIP  planners  should 
they  need  to  perform  'what-if  or  other  relatively  simple  plan  visualizations.  This  is  not  meant  to  imply 
we  are  eliminating  the  current  direct  request  'channel'  between  DIP  planners  and  flight  planners.  The 
DIP  planners'  requests  to  flight  planners  are  typically  for  something  more  detailed  than  the  notional 
products  the  mission  planner  needs.  As  a  result,  we  presume  there  will  continue  to  be  a  procedural  path 
by  which  the  DIP  planner  can  continue  to  request  plan  specifications  more  detailed  than  what  they  can 
generate  directly  with  the  notional  planning  tool. 


Utility  of  Graphical  Visualization  in  Flight  Planning 

The  manipulation  of  a  route  specification  is  done  as  an  exercise  in  text  processing.  This  requires  a 
considerable  cognitive  burden  on  the  flight  planner,  because  he  /  she  must: 

•  mentally  map  the  geo-spatial  dimensions  of  the  prospective  flight  onto  the  text  displayed 

•  mentally  map  any  modifications  to  the  current  text  set  onto  an  imagined  geo-spatial  context 

•  maintain  a  working  awareness  of  any  options  or  variations  on  geo-spatial  implications  and 
ramifications  in  his  /  her  imagination  during  the  course  of  a  planning  session 


In  other  words,  the  flight  planner  is  personally  responsible  for  unaided  and  cognitively  burdensome 
realtime  'visualization'  of  a  flight  plan  with  respect  to  geo-space.  Once  a  flight  or  route  specification  is 
(textually)  laid  out  and  recorded,  its  record  can  be  overlaid  on  a  geo-spatial  map  (e.g.,  using  Falcon 
View).  Indeed,  visualizing  a  candidate  route  specification  using  Falcon  View  is  an  action  our  flight 
planner  SME's  stated  they  routinely  do  (cf.  Roth:  2003,  March).  There  are  multiple  reasons  why  such  a 
graphical  visualization  of  the  textual  route  specification  is  important,  such  as: 

•  It  permits  the  planner  to  see  any  anomalous  or  unnecessary  course  features  (e.g.,  'zig  zag’  routing) 
that  may  have  carried  over  from  the  originally-generated  ACFP  output.39 

•  It  permits  a  check  on  what  national  boundaries  are  traversed  in  the  course  of  the  given  routing.40 

•  It  permits  a  check  on  non-geographical  elements  relevant  to  the  routing  constraints  and 
specifications  (e.g.,  FDR.  boundaries;  entry  /  exit  points;  exclusion  zones). 

•  When  recorded  (e.g.,  printed  out),  it  affords  a  visualization  artifact  that  can  be  forwarded  to  (e.g.)  the 
DIP  planner  to  aid  him  /  her  in  his  parallel  planning  work.41 


However,  there's  no  direct  or  realtime  support  for  visualizing  the  prospective  route(s)  at  the  point  such  a 

capability  would  be  most  useful  -  i.e.,  during  the  planning  process  itself. 

Comments  and  Analysis: 

The  current  arrangement  (visualization  after  recording  a  candidate  flight  plan)  has  the  following  effects: 

•  It  splits  user  attention  between  two  distinct  on-screen  applications  during  any  repeated  cycles  of  plan 
-  record  -  visualize  -  edit  actions. 

•  It  doubles  the  number  of  applications  with  which  the  user  must  interact  in  the  course  of  jointly 
visualizing  and  manipulating  route  specifications. 

•  It  delays  comprehensive  visualization  of  a  route  product  until  that  product  has  been  stored  and  can 
be  graphically  overlaid  on  a  map. 

•  This  delay  necessarily  forces  the  flight  planner  to  go  through  one  plan  /  visualize  cycle  before  he  / 
she  has  the  first  cue  on  problems. 

•  The  range  of  problems  apparent  only  after  this  first  cycle  may  well  include  things  the  planner  could 
not  or  did  not  take  into  account  owing  to  cognitive  overload. 

•  This  arrangement  therefore  heightens  the  risk  of  missing,  misconstruing,  or  misapprehending 
relevant  plan  elements  on  the  first  pass. 


39  Cf.  Roth  (2003,  March) 

40  KA  visit  to  XOCZ,  December  2002;  Roth  (2003,  March) 

41  KA  visit  to  XOCZ,  December  2002 
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This  arrangement  therefore  reduces  the  probability  of  generating  a  comprehensively  'correct'  or 
'viable'  flight  plan  on  the  first  pass. 


These  and  other  factors  make  the  current  arrangement  one  which  increases  cognitive  and  procedural 
burdens  on  the  user,  increases  the  opportunities  for  errors,  increases  the  minimum  time  necessary  to  do 
the  flight  planning  function,  and  hence  decreases  the  nominal  efficiency  of  the  flight  planning  activities. 

By  the  middle  of  our  Phase  II  GAMAT  Phase  II  effort  we  had  begun  probing  our  SME's  on  the 
perceived  utility  of  adding  a  graphical  component  to  the  standard  flight  planning  IT  suite.  The 
responses  we  received  were  uniformly  positive  toward  this  idea.  As  a  result,  we  elected  early  on  to 
make  graphical  support  for  flight  planning  a  key  attribute  of  the  WCSS  recommendations  we  would 
make  in  Phase  II. 


Summary 

The  issues  and  trends  outlined  earlier  in  this  chapter  illustrate  what  we  came  to  believe  are  the  primary 

problems  capable  of  being  addressed  and  ameliorated  using  WCSS  innovations.  By  late  summer  2003 

we  had  come  to  concentrate  on  the  following  features  or  capabilities  as  the  focal  themes  for  our  Phase  II 

WCSS  design  work: 

•  Incorporation  of  real-time  graphical  visualization  in  the  IT  support  aids  providing  the  flight  planning 
staff. 

•  Incorporation  of  new  route  manipulation  capabilities  leveraging  this  new  graphical  representation 
(e.g.,  via  direct  manipulation  of  on-screen  elements). 

•  Renovation  of  the  current  and  /  or  next-generation  F2  Database  (or  equivalent)  to  permit  addressing 
routes  at  a  minimum  of  two  levels  of  granularity. 

•  Leveraging  the  implied  imposition  of  a  more  structured  organizational  schema  for  route  data  to  make 
maintenance  of  the  flight  planners'  route  specification  database  both  more  efficient  and  more 
effective. 

•  Designing  flight  planning  IT  aids  such  that  they  were  of  utility  to  the  broader  population  of  TACC 
users  (i.e.,  not  designing  solely  for  the  experienced  flight  planners). 

•  Making  provision  for  supporting  other  TACC  players  (most  particularly  the  mission  planners)  with  a 
capability  for  generating  notional  flight  plans  without  having  to  request  the  flight  planners  do  it  for 
them. 

•  Illustrating  the  utility  of  facilitating  TACC  team  situation  awareness  on  constraint  and  alert 
conditions  affecting  mission  /  flight  viability,  but  not  directly  and  immediately  inspectable  with 
current  individual  tools. 
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The  payoffs  from  emphasizing  these  themes  in  our  Phase  II  WCSS  designs  were  expected  to  come  from 
new  capabilities  to: 

•  make  route  rationale  and  constraints  more  visible; 

•  facilitate  all  TACC  team  members'  abilities  to  understand,  evaluate  and  revise  a  flight  plan; 

•  afford  mission  planners  more  information  on  options  and  alternatives; 

•  allow  more  timely  capture  and  presentation  of  information  necessary  for  better  situation  awareness 
(SA); 

•  eliminate  current  ‘blind  spots’  in  the  TACC  process  path; 

•  enable  more  proactive  response  across  the  organization;  and 

•  reduce  mission  delays  and  mission  ‘no-gos’ 


Beyond  this,  we  wanted  to  promote  TACC-wide  team  collaboration  as  discussed  in  Chapter  1.3.  This 
meant  that  any  flight  planner  WCSS  innovations  we  prescribed  would  have  to  be  framed  in  the  context 
of  overall  team  requirements  and  not  just  those  of  the  flight  planners  per  se. 

The  specific  WCSS  designs  developed  and  presented  as  the  outcomes  of  our  GAMAT  Phase  II  effort 
will  be  presented  in  Chapters  1.5  and  1.6. 
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1.5  Work-Centered  Design  Concepts  to  Support  TACC  Flight  Planning-related 

Collaborative  Work 


This  chapter  will  introduce  the  WCSS  design  concepts  generated  during  the  Phase  II  GAMAT  effort 
which  address  the  issues  and  themes  discussed  with  respect  to  TACC  collaboration  in  Chapter  1.3.  The 
chapter  will  begin  with  an  overview  of  the  focal  topics  we  selected  for  design  intervention  generally, 
and  then  proceed  to  a  discussion  of  how  we  believe  our  prior  WCSS  analyses,  concepts,  and  prototypes 
can  be  extended  to  provide  a  collaborative  suite  supporting  all  of  TACC.  In  a  subsequent  chapter  we 
shall  address  our  more  specific  Phase  II  WCSS  recommendations  deriving  from  the  review  of  flight 
planning  in  Chapter  1 .4. 


Overview:  Two  Key  Foci  for  Oiir  Design  Prescriptions 

The  Phase  II  GAMAT  project  was  comprised  of  multiple  tasks,  each  of  which  had  its  own  context  and 
objectives.  With  regard  to  the  new  WCSS  design  component  of  the  project,  there  were  two  primary 
streams  of  work: 

•  Analyzing  TACC  operations  for  collaborative  information  technology >  needs  and  opportunities.  This 
aspect  of  the  Phase  II  work  was  dedicated  to  assessing  the  prospects  for  employing  IT  to  support 
interpersonal  and  inter-unit  collaboration  in  TACC’s  planning  and  execution  functions. 

•  Analyzing  planning  and  execution  functions  toward  formulating  key  WCSS  inter\>ention 
opportunities.  This  aspect  of  the  Phase  II  work  was  dedicated  to  assessing  the  prospects  for 
employing  WCSS  to  better  support  TACC  users  in  the  decision  making  functions  they  perform  in 
the  course  of  planning  and  monitoring  missions. 


In  this  and  a  subsequent  chapter  we  shall  review  how  we  pursued  these  two  themes  during  Phase  II. 
One  way  of  characterizing  the  primary  outcomes  of  our  Phase  II  work  is  to  distinguish  them 
figuratively,  in  terms  of  the  manner  in  which  they  address  their  subject  matter.  One  is  a  'horizontal' 
dimension,  'cutting  across’  TACC  units  and  positions,  along  which  we  determined  we  needed  to  better 
organize  our  WCSS  deployment  objectives.  This  'horizontal'  dimension  is  the  one  applicable  to  the 
collaborative  issues  discussed  in  this  chapter.  The  other  is  a  'vertical'  dimension  along  which  we  had  to 
prescribe  visualization  modularity  in  addressing  what  we  considered  to  be  the  single  more  important 
representational  and  visualization  deficiency  in  TACC  as  a  whole.  Discussion  of  this  second  theme  will 
occur  in  a  subsequent  chapter. 


51 


The  'Horizontal'  Dimension:  Cross-Position  WCSS  Utility 

Since  the  first  AFRL/HE  WCSS  project  (HISA  -  FY99  and  FYOO),  we  had  given  consideration  to 
addressing  the  entire  scope  of  TACC  work  and  designing  IT  innovations  to  support  that  range  of  users 
and  functions.  More  specifically,  thought  was  given  to  what  WCSS  suite  or  toolkit  would  provide 
comprehensive  support  for  TACC  as  a  whole.  In  each  of  the  TACC  WCSS  projects  to  date,  our  AFRL 
team  has  ended  up  focusing  (most  often  at  TACC  request)  on  one  or  another  role  or  function. 
Accordingly,  our  emphasis  on  demonstration  prototypes  has  translated  these  more  narrow  foci  into 
WCSS  designs  crafted  to  fit  one  or  another  position  or  function.  In  Phase  II  we  attempted  to  take  a  step 
back  and  evaluate  once  again  the  prospects  for  an  overall  suite  of  WCSS  tools  encompassing  both  the 
WCSS  designs  already  developed  (and  demonstrated,  and  in  some  cases  even  deployed)  as  well  as  those 
which  we  foresaw  as  future  opportunities. 

As  of  the  end  of  Phase  II,  our  AFRL  team  had  in  effect  completed  a  multi-year  examination  of  the 
diverse  units  and  positions  contributing  to  the  TACC  mission  and  flight  planning  process  path.  This  had 
given  us  a  broader  perspective  from  which  we  could  see  the  wider  functional  and  procedural  contexts 
and  ramifications  for  the  WCSS  concepts  we'd  developed  up  until  then.  By  and  large,  the  result  was  that 
we  had  begun  to  see  the  broader  (cross-position;  cross-unit)  applicability  of  some  prototypes  we  had 
previously  designed  with  regard  to  one  or  another  position  or  function.  This  in  turn  meant  we  needed  to 
stop  and  take  the  time  to  re-evaluate  those  prototypes  in  terms  of  how  their  features  might  be 
generalized  across  units  and  positions  so  as  to  fit  within  a  coherent  TACC  WCSS  suite  (as  opposed  to 
the  collection  of  standalone  tools  our  previous  efforts  had  produced). 


A  Comment  on  How  the  WCSS  Approach  Facilitated  Collaborative  Utility  Assessments 

Though  one  can  find  some  variations  in  the  definitions  and  characterizations  employed  to  explain  work- 
centered  design  and  work-centered  support  systems,  these  are  minor.  The  dominant  and  central  theme 
in  WCD  is  that  user  interfaces  and  tools  should  be  crafted  to  reflect  the  form  and  the  flow  of  specific 
work  activities.  With  sufficiently  cogent  and  perceptive  analysis  of  these  specific  work  activities,  the 
essential  elements  of  a  given  work  activity  are  identified  and  correlated  with  elements  of  the  work- 
centered  designs  (including  the  composite  configuration  and  interplay  for  a  set  of  multiple  WCSS 
products). 

By  focusing  on  the  work  itself  (its  topology,  its  structure,  its  flow,  and  its  context)  WCD  seeks  to  fit  the 
information  technology  to  what  its  user  does.  Other  aspects  of  the  work  milieu  (e.g.,  role  definitions, 
organizational  structures,  and  especially  the  affordances  and  constraints  of  particular  products  and 
implementations)  are  treated  as  less  critical  to  the  specification  of  work-centered  designs  than  they  are  in 
conventional  engineering  practices.  Granted,  these  other  factors  influence  the  final  WCSS  outcomes, 
but  they  don't  uniquely  determine  what  these  outcomes  should  be. 

Beginning  with  the  HISA  project  in  1999,  our  AFRL  team  has  sought  to  identify,  analyze,  and  codify 
the  key  elements  defining  TACC's  mission  planning  and  sortie  execution  functions.  By  concentrating 
on  these  more  abstract  features  of  the  work  activities,  we  have  developed  WCSS  design  concepts  which 
reflect  the  nature  of  the  work  accomplished  by  TACC,  and  which  do  so  with  a  degree  of  generality 
affording  us  the  ability  to  disentangle  ourselves  from  transient  details  of  hardware,  software,  procedural, 
and  even  organizational  factors. 
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One  advantage  of  this  relatively  abstracted  approach  is  that  the  resultant  WCSS  concepts  are  not  tightly 
coupled  to  the  specifics  of  a  given  position,  support  suite,  or  procedure.  Our  present  objective  of 
assessing  WCSS  in  light  of  TACC-wide  collaboration  illustrates  the  payoff  to  be  had  from  this 
approach.  Had  our  previous  designs  been  too  closely  tailored  to  the  task  performance  and  work 
requirements  of  one  or  another  specific  position  (as  implemented  by  particular  persons  at  a  particular 
time  and  within  a  particular  organizational  state),  they  would  have  proven  'brittle'  in  the  sense  of 
requiring  major  rethinking  and  renovation  to  be  expanded  to  serve  other  positions  than  the  one  originally 
targeted  in  our  WCSS  research  and  development.  The  WCSS  concepts  generated  to  date  are  reflective 
of  the  general  work  to  be  done  and  not  the  peculiarities  of  how  one  or  another  person  or  unit  does  that 
work. 

This  means  expanding  these  existing  WCSS  concepts  to  support  multiple  roles  across  the  entire  TACC 
team  doesn't  require  a  total  rethinking  of  their  purposes  or  essential  design  elements.  Instead,  the 
primary  innovation  is  to  evaluate  who  else  can  constructively  use  those  generalized  features  and 
capabilities  these  earlier  concepts  provided  their  original  target  users.  In  other  words,  a  coherent  WCD 
approach  based  on  a  deep  and  generalized  understanding  of  the  overall  work  (e.g.,  its  objectives,  critical 
elements  of  information,  constraints,  limitations,  etc.)  can  be  'robust'  in  the  sense  that  changing  other 
elements  of  the  work  milieu  (e.g.,  specific  workers,  organizational  structures,  deployment  platforms) 
does  not  automatically  mean  junking  the  existing  WCSS  concepts  and  having  to  create  them  all  over 
again. 

The  primary  thrust  in  expanding  our  WCSS  coverage  to  support  TACC  team  collaboration  is  therefore 
an  evaluation  of  the  extent  to  which  particular  capabilities  should  be  made  available  across  roles, 
position,  and  organizational  units.  In  the  next  section  we  shall  illustrate  such  an  evaluation  in  terms  of 
what  broader  user  audience  we  now  see  for  selected  AFRL  WCSS  products. 


Assessing  Cross-Position  Utility  for  WCSS  Prototypes  Created  to  Date 

The  procedure  used  in  this  re-evaluation  was  to  consider  what  features  or  design  elements  of  a  given 
WCSS  prototype  concept  would  be  useful  for  positions  other  than  the  one(s)  which  served  as  the 
original  target  audience.  Of  most  importance  to  this  discussion  were  the  results  of  this  re-evaluation 
with  regard  to  four  WCSS  prototypes  -  the  Port  /  MOG  Viewer;  a  summary  workstream  SA  aid;  the 
GAMAT  weather  tool  (WCSS-GWM;  WMT);  and  a  mission  planning  tool.  In  the  tables  below  we  shall 
review  these  four  concepts  in  a  series  of  summary  tables.  Within  each  table  the  concept  and  its  original 
target  audience  (users;  roles)  will  be  cited.  Then  the  primary  features  of  that  concept  will  be 
enumerated.  Finally,  a  list  of  potential  users  (beyond  the  scope  of  the  original  target  audience)  will  be 
provided  to  illustrate  the  extent  to  which  the  concept  (or  a  variation  thereon)  could  be  propagated 
beyond  its  original  demonstration  context. 
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The  Port  Viewer:  Visualization  of  Traffic  Throughput  at  a  Given  Port 

The  first  successful  AFRL  WCSS  design  concept  was  the  Port  Viewer  (also  known  as  the  ’MOG 
Viewer')  developed  in  1999  during  the  HISA  project.  The  Port  Viewer  was  originally  designed  as  one 
of  three  canonical  'viewers’  (summary  displays)  reflecting  the  three  canonical  subcategories  of  reference 
relating  to  an  overall  mission.  These  three  subcategories  were: 

•  Port  -  each  of  the  two  airfields  at  the  departure  and  arrival  ends  of  a  mission  /  flight. 

•  Package  -  the  set  of  tangible  or  discrete  items  to  be  accounted  for  in  planning  and  executing  a 
mission  (e.g.,  aircraft;  crew;  documentation;  cargo,  etc.). 

•  Passage  (later  'En  Route')  -  the  intervening  process  by  which  the  mission’s  Package  executed  a 
physical  transit  from  the  departure  Port  to  the  arrival  Port. 

During  the  course  of  the  HISA  project,  our  AFRL  team  was  instructed  to  focus  on  the  specific  problem 
of  maximum-on -ground  (MOG)  -  i.e.,  the  condition  of  having  too  many  aircraft  on  the  ground  at  a  given 
airfield  (relative  to  that  airfield's  stated  limitations).  As  a  result,  two  things  occurred.  First,  the  Passage 
and  Package  viewers  were  set  aside  and  not  developed  beyond  their  original  notional  sketches.  Second, 
the  Port  Viewer  was  designed  more  specifically  to  serve  as  a  rapid  situation  awareness  aid  for  MOG 
conditions.  In  various  forms,  this  design  concept  has  been  developed  and  implemented  in  multiple 
editions  during  the  intervening  years.  Its  perceived  utility  has  clearly  been  acknowledged  by  roles  / 
positions  other  than  the  channel  mission  planners  for  whom  it  was  first  conceived.  A  summary  of  the 
collaborative  prospects  for  the  Port  Viewer  is  provided  in  Table  1 .5-1 . 

Table  1.5-1 :  Collaborative  Prospects  for  the  Port  /  MOG  Viewer  Concept 


PORT 
VIEWER 
(aka  MOG 
Viewer) 

HISA  Project 
1999 

Mission 

Planners 

•  Structured  view  of  Port  traffic 
throughput 

•  Alert  coding  for  MOG  occurrence 

•  Flight  planners 

•  Flight  managers 

•  Execution  staff 

•  Management 

•  Wings  /  Squadrons 

•  APCC 

In  many  respects,  a  re-evaluation  of  the  Port  Viewer  in  light  of  TACC-wide  collaboration  entails  a 
return  to  the  generality  of  the  original  HISA  concept  -  i.e.,  the  notion  of  a  summary  overview  for  port 
traffic  and  not  just  a  MOG-specific  gadget.  Tracking  traffic  throughput  at  a  given  port  is  something  of 
utility  for  almost  all  positions  within  the  TACC  process  path.  As  such,  a  Port  Viewer  could  -  with  little 
modification  from  the  currently-deployed  prototypes  -  serve  as  a  common  tool  for  the  wider  audience 
cited  in  Table  1.5-1.  Because  the  visualization  requirements  are  essentially  identical  across  this 
population  of  potential  users,  there  is  no  perceived  need  to  tailor  or  propagate  the  Port  Viewer  concept 
into  a  set  ot  related  tools.  Accordingly,  the  means  for  elevating  the  Fort  viewer  from  a  specific  aid  to  a 
component  of  an  overall  TACC  collaborative  toolkit  is  to  simply  propagate  a  deployable  version  to  a 
wider  audience. 


54 


The  Mission  Status  Display:  Summary >  Situation  Awareness  on  the  TACC  Work  Stream 


'Mission  Status  Display'  was  the  first  label  given  to  the  concept  of  a  summary  listing  of  all  active 
mission  'cases'  making  their  way  through  TACC  from  initial  planning  to  final  execution.  The  concept  of 
an  ordered  list  of  active  'cases’  dates  back  to  the  original  designs  sketched  out  during  the  HIS  A  project 
(1999  -  2000)  in  relation  to  channel  mission  planners.  However,  the  work  stream  SA  display  aspects 
were  subordinated  to  the  alerting  aspects,  for  which  a  prototype  was  produced  in  2000.  This  concept 
surfaced  again  the  following  year  in  the  IFM  project,  when  once  again  our  analyses  of  planning 
activities  (in  this  case  involving  flight  managers)  suggested  such  a  summary  work  stream  overview  was 
necessary.  Since  then,  this  concept  has  been  commonly  referred  to  as  'the  to-do  list',  connoting  its  role 
as  the  user's  window  onto  the  pending  and  active  workstream.  During  the  GAMAT  phase  I  work,  a 
'Sortie  Palette'  was  developed  and  demonstrated  as  the  first  working  software  prototype  for  this  concept. 
The  collaborative  prospects  for  this  concept  are  illustrated  in  Table  1 .5-2. 

Table  1.5-2  Collaborative  Prospects  for  the  Mission  Status  Overview  Display 
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MISSION 
STATUS 
DISPLAY 
(aka  'To-Do 
List') 

IFM  Project 
2000-2001 
(cf.  the  'Sortie 
Palette'  feature  in 
the  GAMAT 
GWM-WCSS 

Flight 

Managers 

•  Summary  overview  of  TACC 
workstream 

•  Ordered  listing  of  active  mission 
'cases' 

•  Summary  mission  ID  info 

•  Summary  alert  /  status  coding  for 
individual  missions  /  cases 

•  Ability  to  rapidly  assess  the  status  of 
the  overall  workstream 

•  One-click  drilldown  to  individual 
mission  record(s) 

•  Mission  planners 

•  Flight  planners 

•  Execution  staff 

•  Management 

•  WX  staff 

•  DIP  planners 

•  Barrelmasters 

•  APCC 

•  Wings  /  Squadrons 

As  Table  1.5-2  illustrates,  the  concept  of  a  summary  workstream  overview  is  of  use  to  just  about 
everyone  involved  in  the  TACC  mission  planning  and  execution  process.  Indeed,  reference  to  the 
workstream  comprised  of  'cases'  (individual  missions  being  processed)  is  the  most  general  conceivable 
information  requirement  for  TACC  operations.  Accordingly,  a  summary  display  providing  situation 
awareness  over  this  workstream  is  the  most  generally-useful  information  aid  conceivable  for  TACC.  As 
such,  this  sort  of  workstream  overview  is  in  effect  the  'spine'  (most  critically  informative)  for  an  overall 
TACC  collaborative  IT  suite. 

However,  as  was  the  case  for  the  Port  Viewer,  this  mission  status  listing  is  sufficiently  generic  that  there 
is  little  if  any  need  to  tailor  or  differentiate  variants  to  support  different  roles  or  units  within  TACC. 
Accordingly,  the  means  for  elevating  the  mission  status  'to-do  list'  from  a  specific  aid  to  a  component  of 
an  overall  TACC  collaborative  toolkit  is  to  simply  propagate  a  deployable  version  to  a  wider  audience. 
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The  GAMA  T  Weather  Tool:  Visualization  of  WX  Impacts  on  Mission  and  Flights 


The  WCSS-GWM42  weather  information  visualization  tool  created  and  developed  under  the  aegis  of  our 
GAM  AT  ATD  has  been  the  object  of  the  longest  continuous  development  and  refinement  process  of  all 
the  AFRL  WCSS  products  to  date.  Though  it  has  had  obvious  significance  in  providing  single-point 
meteorological  visualization  and  reference  support  to  TACC  personnel,  even  in  prototype  form,  the 
WCSS-GWM  has  perhaps  an  even  greater  eventual  significance  for  its  more  generic  features  as  a  work- 
centered  interface. 

The  most  important  aspect  of  this  generic  significance  is  related  to  the  fact  that  the  WCSS-GWM  is  the 
first  WCSS  prototype  to  emphasize  geo-spatial  visualization  (i.e.,  maps).  As  a  natural  phenomenon, 
weather  correlates  with  geographical  location.  As  a  result,  visualizing  meteorological  data  is  most 
effectively  done  through  representations  correlated  with  geographical  features.  However,  it  is  not  only 
the  weather  which  is  effectively  visualized  with  respect  to  geography.  Flight  routing  is  similarly 
correlated  with  geography,  because  (e.g.): 

•  Flight  departure  and  arrival  endpoints  are  indexed  with  respect  to  geographically-specified  locations 
(i.e.,  airfields). 

•  Flight  routes  are  defined  with  respect  to  geographical  locations  (waypoints;  lat  /  long  coordinates, 
etc.). 

•  The  majority  of  operationally-delineated  routing  elements  (e.g.,  exclusion  zones;  areas  of  ATC 
responsibility)  are  defined  with  direct  or  derivative  regard  to  geographical  locations  (e.g.,  an  area 
defined  by  a  given  radius  around  a  fixed  geo-spatial  point). 

•  The  primary  means  for  tracking  flight  progress  is  through  aircrew  reports  citing  geographical 
location. 

•  The  ancillary  diplomatic  clearance  factors  bearing  on  routing  opportunities  and  limitations  are 
delineated  with  respect  to  geographical  locations  (the  national  territory  being  transited). 


As  a  result,  the  sort  of  geo-spatial  visualization  of  such  clear  utility  in  visualizing  weather  in  the  WCSS- 
GWM  recommends  itself  for  visualizing  flight  routes  for  planning  and  execution  purposes.  In  contrast, 
some  of  the  WX-specific  features  and  design  emphases  embedded  in  the  WCSS-GWM  prototype  are  of 
lesser  criticality  for  a  flight  planner  than  for,  say,  a  weather  squadron  staffer.  A  breakdown  of  the 
WCSS-GWM  features  suitable  for  the  WX  shop  specifically  and  the  TACC  team  generically  is 
illustrated  in  Table  1.5-3. 


42  WCSS-GWM  is  an  acronym  for  'Global  Weather  Management  -  Work  Centered  Support  System'.  This  was  the 
culminating  title  for  this  product.  At  various  times  and  among  various  people  this  tool  has  also  been  known  as:  'Weather 
Management  Tool  (WMT)’;  'GAMAT  Weather  Tool';  and  simply  'GAMAT'.  For  the  purposes  of  this  report,  we  shall  attempt 
to  use  the  final  label  WCSS-GWM  exclusively. 
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Table  1.5-3:  Collaborative  Prospects  for  the  GAMAT  Weather  Tool 
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GWM- 
WCSS 
(aka  ’GAMAT 
tool’;  ’Weather 
Mgmt  Tool’) 
GAMAT 
Projects 

2001  -2003 

WX  Shop 

•  Single  point  access  to  diverse  WX 
data  streams 

•  Fusion  of  WX  data  into  a  single 

WX  overview 

•  Execution  staff 

•  Flight  managers 

•  Execution  supervisors 

•  Wings  /  Squadrons 

•  Flight  crews 

•  Central  geo-referenced 
visualization  display 

•  Multi-layered  display  elements 

•  Ordered  set  of  relevant  data  /  info 
layer  options 

•  Ability  to  select  /  mix  overlays 
interactively 

•  Vertical  flight  profile  view 

•  All  the  above  plus.. . 

•  Mission  planners 

•  Flight  planners 

•  Planning  supervisors 

•  DIP  planners 

•  Barrelmasters 

•  APCC 

In  this  third  example  we  see  something  different  from  what  our  collaborative  utility  assessment 
developed  with  respect  to  the  two  preceding  examples.  In  those  earlier  cases,  the  WCSS  tools  were 
evaluated  to  be  of  wider  utility  in  more  or  less  their  original  /  current  forms.  In  the  case  of  the  WCSS- 
GWM,  there  is  a  distinction  to  be  drawn  between  (a)  the  subset  of  WCSS-GWM  features  of  primary 
relevance  to  the  WX  shop  alone  versus  (b)  the  subset  of  WCSS-GWM  features  of  wider  relevance  to  the 
TACC  team  as  a  whole. 

This  distinction  can  be  framed  with  respect  to  temporality.43  Weather  is,  of  course,  a  very  changeable 
phenomenon.  Weather  information  -  including  composite  visualizations  -  have  a  relatively  short  period 
of  usability  before  changes  mandate  an  updated  record.  This  temporal  constraint  results  in  detailed  WX 
data  being  of  primary  utility  to  those  TACC  roles  who  must  deal  with  flights  /  missions  in  the  hours  just 
before  launch  and  throughout  the  execution  phase. 


43  To  be  fair,  there’s  more  than  one  context  for  framing  this  differentiation.  In  light  of  this  report's  earlier  emphasis  on 
temporality  in  TACC  operations,  this  particular  context  was  judged  to  be  especially  pertinent. 
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Flight  routes,  on  the  other  hand,  are  amenable  to  longer  unmodified  duration  (e.g.,  from  planning  weeks 
in  advance  through  the  execution  phase).  This,  combined  with  the  aforementioned  primacy  of  geo¬ 
spatial  reference  in  route  visualization,  suggests  that  generalization  and  broader  dissemination  of  the  sort 
of  geo-spatial  capabilities  exemplified  by  the  WCSS-GWM  could  serve  as  the  basis  for  route-oriented 
information  aiding.  Phrased  another  way,  one  can  readily  see  the  WCSS-GWM  as  an  example  of  a 
general  geo-spatial  visualization  tool  whose  specific  form  and  functionality  are  attuned  to  the  particular 
work  of  the  weather  shop.  Accordingly,  one  can  just  as  readily  imagine  another  variant  on  such  a 
generic  visualization  tool  configured  more  to  fit  the  requirements  of  those  other  TACC  roles  whose 
focus  is  on  routes.44 

The  subdivision  of  WCSS-GWM  features  in  Table  1.5-3  is,,  therefore,  necessary  to  weed  out  those 
features  peculiar  to  the  prototype's  original  target  user  population  and  to  highlight  those  features  of  more 
general  relevance.  This  doesn't  mean  the  two  sets  of  features  are  mutually  exclusive.  Neither  does  it 
necessarily  imply  that  weather-oriented  features  should  be  strictly  segregated  from  route-oriented 
features.  Weather  personnel  need  to  reference  routes  -  for  example,  in  determining  which  regions 
should  be  covered  in  the  current  shift's  chart  update  process.  Conversely,  execution  cell  personnel  need 
to  be  able  to  reference  weather  conditions  -  for  example,  in  assessing  the  feasibility  of  a  proposed 
alternative  route  or  the  viability  of  a  diversion  to  one  or  another  airfield. 

The  point  is  that  in  the  case  of  the  WCSS-GWM,  we  can  discern  a  basis  for  generalizing  the  specific 
WCSS  prototype's  key  feature  (geo-spatial  visualization)  to  serve  as  the  basis  for  a  more  generic  (and 
more  broadly  deployed)  work-centered  aid.  The  resultant  route-oriented  geo-spatial  visualization  tool 
(termed  the  Flight  Visualization  Tool  -  FVT)  will  be  discussed  in  more  detail  later  in  this  report. 


The  Flight  Planning  Palette:  A  Unified  Aid  for  Mission  and  Flight  Planning 

During  the  IFM  (Integrated  Flight  Management)  project  (2000  -  2001),  an  AFRL  team  observed  and 
analyzed  the  work  of  the  then-new  flight  manager  (FM)  position.  One  of  the  outcomes  of  that  effort  was 
a  concern  for  diversity  of  disparate  tools  an  FM  had  to  invoke  and  manipulate  in  the  course  of  finalizing 
a  flight  plan  and  assembling  the  requisite  documentation  to  'paper  the  crew'.  Our  WCSS  prescription  for 
this  issue  was  a  single  unified  'Flight  Planning  Palette’  which  provided  a  single  on-screen  workspace  for 
generating  the  route  (and  other)  specifications  and  for  tracking  the  FM's  procedural  progress  on  a  given 
mission.  This  concept  was  briefed  to  the  FM's  and  other  TACC  staff  in  spring  2001.  At  that  point, 
AFRL  involvement  with  the  concept  stopped.  As  we  later  learned,  the  FM's  were  sufficiently 
enthusiastic  about  the  Flight  Planning  Palette  concept  to  have  TACC  contractors  generate  them  a 
working  prototype.  This  prototype  has  been  deployed  for  FM  use  under  the  name  'Sortie  Manager'. 


44  This  quite  clearly  illustrates  the  fact  that  our  WCSS  research  efforts,  though  generally  undertaken  with  respect  to  broad  or 
generic  cnaracterlzanons  orxne  target  work  processes,  nave  Historically  ended  up  focusing  on  relatively  more  narrowly- 
defined  prototypes  geared  to  the  specific  needs  of  one  or  another  TACC  position  or  unit.  Geo-spatial  route  visualization  was 
nominated  as  a  possible  aid  for  channel  mission  planners  back  in  the  1999  HISA  project,  but  it  was  ruled  out  as  suboptimal 
for  the  purposes  of  planning  a  'mission'  (a  goal-oriented  task  specification)  as  contrasted  with  a  'flight'  (a  physical  movement 
between  departure  and  arrival  ports  to  accomplish  the  purposes  of  an  associated  mission). 
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As  was  the  case  with  the  WCSS-GWM  earlier,  this  Sortie  Manager  tool  embodies  features  which  can  be 
subdivided  with  respect  to  (a)  those  which  are  most  pertinent  to  flight  managers  (and  similar  planning 
personnel)  and  (b)  those  which  recommend  themselves  as  pertinent  to  the  objectives  and  tasking  of  other 
roles.  This  is  illustrated  in  Table  1.5-4. 

Table  1.5-4:  Collaborative  Prospects  for  the  Flight  Planning  Palette 
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PLANNING 

PALETTE 

IFM  Project 
2000  -  2001 
Implemented  as 
FM's  'Sortie 
Manager'  tool 

Flight 

Managers 

•  Working  area  for  generating  flight 
documentation 

•  Organized  to  reflect  stepwise 
planning  procedure  (and  progress 
thereon) 

•  Flight  Planners 

•  Mission  Planners 

•  Fused  accessibility  to  relevant 
mission  data  /  planning  info  in  a 
single-point  reference  asset. 

•  Single-point  reference  on  mission  / 
flight  planning  process 

•  Single-point  drilldown  capability  to 
supporting  /  detailed  planning 
documentation 

•  All  the  above  plus .. . 

•  Execution  staff 

•  Supervisors  (for 
planning  oversight) 

•  Wings  /  Squadrons 

•  Flight  crews 

•  Barrelmasters 

•  APCC 

As  Table  1.5-4  indicates,  the  'working  area'  aspects  of  the  Sortie  Manager  are  of  primary  importance  to 
those  whose  tasking  includes  generating  flight  plans  and  other  crew  documentation.  However,  the  form 
and  organization  of  the  original  Flight  Planning  Palette  concept  was  also  designed  to  provide  a  coherent 
single  reference  asset  for  a  given  mission.  In  relation  to  this  'reference'  aspect  of  the  WCSS  design 
concept,  we  can  now  see  a  larger  audience  to  whom  its  utility  can  be  extended.  There  are  a  variety  of 
TACC  team  members  who  are  not  directly  involved  in  the  final  flight  planning  process,  but  whose  own 
work  could  be  facilitated  (if  only  under  special  circumstances)  by  an  ability  to  call  up  a  structured 
planning  record  to  see  (e.g.)  where  the  planning  process  stands,  what  rationale  or  parameters  were 
included  in  generating  the  current  plan,  and  so  forth.  In  other  words,  this  concept  (in  generic  form)  can 
serve  not  only  as  an  interactive  tool  for  those  planning  flights,  but  also  a  situation  awareness  aid  to  allow 
other  TACC  team  members  to  monitor  or  evaluate  the  planning  process  or  the  plan  itself. 

As  was  the  case  in  differentiating  among  features  and  generalizing  the  WCSS-GWM,  the  Flight 
Planning  Palette  can  be  seen  as  a  specific  instance  of  a  more  general  tool.  This  notion  intersects  the  idea 
of  a  more  general  Flight  Visualization  Tool  because  we  are  now  able  to  see  how  geo-spatial 
visualization  could  constructively  support  flight  (as  contrasted  with  mission)  planning.  The 
interrelationship  between  a  generalized  planning  palette  and  a  generalized  flight  visualization  aid  will  be 
discussed  in  more  detail  later  in  this  report. 


59 


Summary 


As  discussed  earlier  in  Chapter  1.3,  fostering  better  overall  team  performance  in  TACC  operations  is 
more  properly  a  matter  of  promoting  better  'coordination'  (e.g.,  uniform  situation  awareness  on  the  work 
stream,  individual  cases,  etc.)  among  specialized  team  members  than  a  matter  of  imposing  more  real¬ 
time  'collaboration'  (i.e.,  work  practices  requiring  joint  attention  and  action  by  multiple  TACC  team 
members).  The  former  (coordination  focus)  sets  the  stage  for,  and  does  not  hinder,  the  latter.  The  latter, 
even  if  successfully  implemented,  does  not  guarantee  the  payoffs  expected  of  the  former. 

None  of  our  earlier  WCSS  prototypes  are  entirely  unsuited  to  deployment  as  collaborative  tools  across 
TACC.  Two  of  the  prototypes  (the  WCSS-GWM  and  the  Flight  Planning  Palette)  incorporate  features 
which  are  both  position-specific  as  well  as  generally  useful  for  a  broader  TACC  audience.  As  it  turns 
out,  these  two  prototypes  are  also  the  ones  of  most  general  utility  (as  information  summary  displays)  to 
the  widest  number  of  TACC  workers.  Ultimately,  TACC's  primary  information  products  are  mission 
and  flight  plans.  This  has  a  number  of  implications.  First,  it  means  that  there  needs  to  be  a  coherent 
means  for  generating  and  documenting  these  plans  -  one  which  facilitates  the  planner's  (or  planners') 
navigation  through  the  work  process  and  subsidiary  tasks.  This  is  the  role  of  the  Flight  Planning  Palette. 
Second,  it  means  that  there  needs  to  be  a  coherent  means  for  displaying  and  addressing  the  actual  flight 
operations  conducted  with  regard  to  these  plans.  This  role  is  exemplified  by  the  WCSS-GWM  (as 
extended  from  its  original  weather-specific  scope  to  include  portrayal  of  flight  information). 

As  a  result,  we  ended  up  framing  our  approach  to  collaborative  WCSS  in  terms  of  extending  or 
expanding  existing  WCSS  concepts  and  prototypes  to  serve  a  wider  TACC  audience.  Though  such  an 
approach  may  seem  merely  'convenient',  it  was  entirely  justified.  Our  previously  role-specific  WCSS 
products  were  designed  with  regard  to  overall  TACC  operations  (and  hence  the  general  scope  of  the 
whole  TACC  team)  from  the  beginning.  Because  AFRL's  WCD  approach  emphasizes  the  work 
environment,  a  properly-executed  WCD  project  should  address  and  reflect  collaborative  opportunities 
for  any  work  environment  in  which  'collaboration'  is  an  essential  feature. 

As  demonstrated  earlier,  some  of  our  WCSS  prototypes  need  not  be  re-conceptualized  or  re-designed  to 
support  an  audience  broader  than  that  for  which  they  were  originally  intended.  The  Mission  Status 
Display  ('to-do-list')  concept,  though  initially  proposed  to  support  mission  planners,  is  generalizable  all 
across  the  TACC  team  because  it  provides  situation  awareness  over  the  workstream  all  team  members 
must  handle  in  some  way  and  at  some  point.  The  Port  /  MOG  Viewer  concept  is  similarly  generalizable, 
though  for  a  different  reason.  It  was  designed  to  provide  specific  situation  awareness  for  a  particular 
thing  (traffic  throughput  at  a  given  airfield)  which,  as  an  essential  feature  of  the  air  mobility  domain,  is 
relevant  to  any  and  all  missions  (and  hence  anyone  involved  in  planning  or  monitoring  such  missions). 
As  a  result,  these  two  WCSS  concepts  will  not  be  discussed  further  in  this  report. 


60 


Additional  Note:  Another  WCSS  Concept  Generated  during  GAMAT Phase  II 

An  additional  note  is  in  order.  In  the  course  of  the  GAMAT  Phase  II  effort  we  invested  considerable 
time  in  examining  and  analyzing  the  relationship  between  the  flight  planning  function  and  the  DIP 
clearance  function.  The  feasibility  and  availability  of  DIP  clearances  was  often  cited  as  a  primary  class 
of  constraints  on  the  flight  planning  process  and  the  ability  to  replan  flights  as  circumstances  demanded. 
However,  no  reference  aid  was  available  to  the  TACC  team  to  provide  them  with  ready,  concise,  and 
easily-interpretable  information  on  the  DIP  status  associated  with  a  given  mission.  In  response  to  these 
determinations,  a  WCSS  'viewer'  concept  for  mission  DIP  data  was  generated  and  briefed  during  the 
latter  stages  of  our  GAMAT  Phase  II  project.  However,  this  concept  was  not  developed  into  a  prototype 
for  a  variety  of  reasons,  including: 

•  Other  WCSS  topics  (most  particularly  flight  visualization)  were  accorded  higher  priority. 

•  The  DIP  status  'viewer'  concept  arrived  relatively  late  in  the  GAMAT  Phase  II  timeframe. 

•  There  were  lingering  uncertainties  about  the  extent  to  which  the  intended  functions  of  this  DIP 
viewer  would  eventually  be  covered  in  features  of  the  oncoming  GDSS  2. 

As  such,  this  DIP  status  display  (called  the  DIP  Summary  Palette)  was  not  included  in  the  earlier  review 
of  precedent  WCSS  prototypes,  and  it  will  not  be  discussed  further  in  the  next  chapter  along  with  our 
flight  visualization  WCSS  concepts.  Documentation  of  the  DIP  Summary  Palette  is  instead  provided  in 
a  separate  Appendix  C. 
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1.6  Work-Centered  Design  Concepts  to  Support  TACC  Flight  Planning  Work 

This  chapter  will  introduce  the  WCSS  design  concepts  generated  during  the  Phase  II  GAMAT  effort 
which  address  the  issues  and  themes  discussed  with  respect  to  the  work-centered  review  of  flight 
planning  in  Chapter  1 .4.  The  chapter  will  begin  with  an  overview  of  the  focal  topics  we  selected  for 
design  intervention,  then  proceed  to  a  discussion  of  the  specific  design  concepts  developed  and 
presented  in  various  meetings  during  the  project’s  timeframe,  culminating  in  the  GAMAT  Phase  II  PMR 
(February  2004). 

In  Chapter  1 .5  we  discussed  the  manner  in  which  two  of  our  existing  WCSS  products  (the  WCSS-GWM 
and  the  Flight  Planning  Palette)  could  be  deconstructed  in  terms  of  the  distinction  between  (a)  those 
design  features  peculiar  to  the  original  target  audience  and  (b)  those  design  features  of  more  general 
utility  across  a  wider  population  of  TACC  team  members.  This  latter  category  is  the  one  we  pursued 
during  the  GAMAT  Phase  II  effort,  in  accordance  with  our  mandate  to  explore  TACC  collaborative 
opportunities.  As  a  result,  the  main  WCSS  design  concepts  generated  during  Phase  II  relate  to 
generalizing  these  features  (i.e.,  geo-spatial  visualization  and  discrete  interactive  planning  workspaces). 
Given  our  project's  Phase  II  focus  on  flight  planners  and  the  flight  planning  process,  we  emphasized 
these  two  generalizations  in  the  context  of  how  they  intersect  with  the  flight  planning  domain. 

In  the  remainder  of  this  chapter  we  shall  introduce  and  discuss  the  central  products  of  our  Phase  II 
design  work.45  First  we  shall  address  integrated  geo-spatial  route  visualization  in  the  form  of  a  proposed 
Flight  Visualization  Tool  (FVT).  Then  we  shall  proceed  to  address  interactive  flight  planning  support  in 
the  form  of  a  proposed  Route  Editor.  In  addition,  we  will  describe  how  these  two  WCSS  concepts  are 
intended  to  interoperate  as  components  of  a  broader  TACC  collaborative  WCSS  toolkit. 


The  ’Vertical'  Dimension  for  WCSS  Intervention:  Supporting  Coherent  Flight  /  Route 
Visualization  for  TACC  Users 

As  discussed  in  the  preceding  chapter,  our  work  during  GAMAT  Phase  II  can  be  figuratively 
characterized  as  focusing  analysis  along  two  'dimensions',  the  first  of  which  was  a  'horizontal'  dimension 
cutting  laterally  across  TACC  positions  and  subunits.  The  second  or  'vertical'  dimension  concerns  the 
need  and  prospects  for  work-centered  visualization  of  routes  within  TACC.  The  rationale  for  our  focus 
on  flight  visualization  during  Phase  II  derives  from  multiple  factors.  The  most  important  and 
compelling  such  factor  was  the  general  lack  of  graphical  support  for  the  flight  planners'  work 
activities  46  This  deficiency  can  be  construed  as  inducing  or  facilitating  several  performance-degrading 
conditions,  including: 

•  Inability  to  quickly  invoke  a  summary  overview  of  a  flight's  designated  route  except  in  the  form  of  a 
detailed  and  relatively  dense  text  record 

45  As  mentioned  in  Chapter  1 .5,  a  third  WCSS  design  concept  generated  during  Phase  II  (the  DIP  Summary  Palette)  is 
addressed  in  a  separate  Appendix  C. 

46  There  are  graphical  tools  available  (most  particularly  FalconView),  but  these  are  secondary  or  auxiliary  resources  with 
respect  to  the  flight  planners'  core  IT  support.  The  use  of  FalconView  appears  to  have  started  and  propagated  mainly  among 
the  flight  managers  rather  than  the  flight  planners.  This  development  began  after  our  2000  -  2001  IFM  project  (during  which 
we  studied  the  inaugural  group  of  FM's),  but  was  evident  at  least  as  early  as  early  2002  (during  GAMAT  Phase  I). 
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•  Heightened  cognitive  burden  for  any  user  attempting  to  understand  a  given  flight  from  the 
conventional  textual  documentation 

•  Heightened  cognitive  burden  involved  in  attempting  to  correlate  textual  flight  or  route  information 
with  other  relevant  data  provided  in  separate  displays  (e.g.,  different  windows  on  the  same  screen) 

•  The  general  difficulties  involved  in  attempting  to  discern  and  analyze  constraints  and  problems  using 
textual  documentation. 

•  Heightened  risk  of  performance  errors  induced  by  having  to  address,  analyze,  and  plan  flights  using 
text  only 

•  Collaborative  difficulties  in  trying  to  communicate  information  or  understanding  of  route  /  flight 
conditions  using  a  textual  record  as  the  primary  or  sole  shared  reference  resource 

•  The  general  unsuitability  of  textual  displays  for  providing  peers  and  supervisors  effective  situation 
awareness  spanning  multiple  missions  (e.g.,  in  the  execution  phase) 

•  The  persistent  and  pointed  interest  shown  by  planning  and  execution  staff  in  the  graphic  capabilities 
developed  in  our  Phase  I  project  for  the  weather  staff 

•  Recurrent  references  made  by  flight  planning  and  other  TACC  SME's  to  their  belief  that  more 
graphically-oriented  visualizations  would  greatly  improve  their  effectiveness  and  efficiency  in 
planning  and  flight  monitoring.47 


As  will  be  seen  more  clearly  in  subsequent  sections  of  this  report,  the  need  for  flight  /  route  visualization 
led  us  to  develop  work-centered  representational  schemata  predicated  on  multiple  layers  or  levels  of 
reference.  In  other  words,  our  visualization  design  work  led  us  to  prioritize  information  composition  in 
relation  to  a  'vertical'  dimension  of  composition  and  /  or  abstraction. 


47  It  is  important  to  emphasize  that  SME  opinions  and  suggestions  are  treated  as  very  important  information  in  the  context  of 
our  work-centered  approach.  Our  knowledge  acquisition  is  conducted  under  the  rubric  of  a  general  principle  to  the  effect  that 
no  one  knows  the  work  better  than  those  who  actually  perform  it.  As  a  result,  we  made  a  point  to  conduct  demonstrations, 
presentations,  and  interviews  to  give  the  SME's  a  regular  update  on  our  views  of  their  work,  their  problems,  and  our  concepts 
for  helping  them.  Conversely,  we  continually  solicited  SME  feedback  to  obtain  opinions,  suggestions,  and  other  data  to  aid 
us  in  evaluating  and  refining  our  ideas  and  proposals. 
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There  is  another  important  sense  in  which  this  flight  visualization  work  represented  interest  in  a  'vertical' 
dimension.  This  sense  has  to  do  with  the  chain  of  command  and  the  organizational  hierarchy  within 
TACC.  As  indicated  in  the  list  of  performance-inhibiting  issues  above,  TACC  supervisory  staff  (e.g., 
seniors)  are  at  a  disadvantage  in  trying  to  maintain  summary  situation  awareness  over  multiple  missions 
while  relying  on  text-intensive  information  displays.  One  of  the  reasons  we  prioritized  route 
visualization  in  our  GAMAT  Phase  II  project  was  our  belief  that  a  coherent  graphical  route  display 
capability  would  be  of  as  much  (if  not  more)  immediate  utility  to  supervisory  staff  as  to  planners 
themselves.  In  other  words,  we  were  operating  with  respect  to  a  secondary  type  of  'verticality'  in  the 
context  of  fostering  better  collaborative  performance  within  the  overall  TACC  team  (cf.  Chapters  1.3 
and  1.5). 


Flight  Planning:  Key  Elements  Underlying  a  WCSS  for  Flight  Planning 

The  GAMAT  Phase  II  WCSS  design  work  was  predicated  on  a  set  of  criteria  which  were  derived  from 
the  information  we'd  gathered  during  our  multiple  KA  efforts  and  the  analyses  of  that  information. 
Generally  speaking,  these  analyses  led  to  three  interrelated  categories  of  themes  and  proposed 
innovations,  culminating  in  a  set  of  WCSS  design  criteria,  as  described  in  the  following  subsections. 


Specific  Functional  Enhancements 

Our  analyses  led  us  to  identify  key  task-related  functions  which  we  felt  needed  to  be  prioritized  as 

payoffs  from  the  WCSS  designs.  These  functions  correlate  with  one  or  more  of  the  TACC  positions  we 

studied  during  the  two  years  of  the  GAMAT  project  to  date  and  /  or  prior  WCSS  projects  at  TACC.  Our 

set  of  prioritized  functional  objectives  can  be  summarized  as  follows: 

Enable  Flight  Planners  to: 

•  more  effectively  visualize  the  route  specifications  that  are  their  primary  work  foci 

•  create,  edit,  and  /  or  manipulate  route  specification  data  in  a  manner  more  efficient  than  is  currently 
the  case  (i.e.,  exclusively  through  text  editing) 

•  reduce  the  risk  of  performance  errors  by  addressing  routes  in  terms  of  graphical  representations  (as 
opposed  to  having  to  imagine  routes  based  on  text  descriptions) 

•  more  efficiently  capture  flight  planning  knowledge  accrued  over  time 

•  better  maintain  their  corporate  flight  planning  knowledge  base  (i.e.,  the  F2  database  and  /  or  its 
evolutionary  successor) 

•  store  and  evolve  this  knowledge  base  in  a  form  more  amenable  to  supporting  other  TACC  team 
members  through  effective  graphic  visualization 
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Enable  Mission  Planners  to: 


•  avail  themselves  of  more  information  on  route  options  and  alternatives 

•  access  this  routing  information  in  a  form  less  demanding  of  expert  interpolation  and  interpretation  than 
currently-available  documentation  (i.e.,  the  textual  route  specifications  currently  in  use) 

•  generate  notional  flight  plans  on  their  own,  without  having  to  rely  on  the  flight  planners  exclusively 

•  use  their  self-generated  flight  plans  to  get  a  head  start  on  the  DIP  clearance  planning  without  having  to 
wait  on  flight  planner  intervention 

Enable  the  entire  TACC  team  to: 

•  efficiently  retrieve  and  view  the  planned  routing  associated  with  a  given  mission 

•  efficiently  retrieve  and  view  the  state  of  DIP  clearances  associated  with  a  given  mission 

•  more  easily  understand  the  temporal  constraints  of  DIP  clearances  currently  in  place  for  a  given 
mission 


General  Operational  Requirements 

More  generally,  we  set  out  to  achieve  certain  broad  objectives  relating  to  overall  TACC  operations  (as 

contrasted  with  individual  roles,  tasks,  and  functions).  Our  set  of  prioritized  operational  objectives  can 

be  summarized  as  follows: 

•  Design  WCSS  visualization  /  display  products  of  sufficient  generality  to  support  a  broader  audience 
within  the  TACC  team. 

•  Design  such  visualization  products  so  as  to  facilitate  rapid  and  effective  situation  awareness  (SA) 
with  respect  to  both  (a)  individual  missions  and  (b)  a  set  of  missions. 

•  Allow  timely  capture  and  presentation  of  facts  and  changes  to  provide  better  situation  awareness. 

•  Make  rationale  and  constraints  associated  with  a  given  route  more  'visible'  (both  literally  and 
figuratively)  and  hence  more  understandable. 

•  Provide  the  capability  for  visualizing  flights  in  a  manner  more  representative  of  those  flights' 
operational  character  (i.e.,  graphically  and  geo-referenced). 
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Technical  Innovations 


Given  the  above-cited  functional  and  operational  objectives,  we  determined  what  particular  technical 

innovations  would  be  needed  to  devise  WCSS.  Our  set  of  target  technical  innovations  can  be 

summarized  as  follows: 

•  Fusion  of  route  info  with  other  key  data  (e.g.,  geography,  weather)  in  a  unified  visualization  scheme 
presented  to  TACC  team  members  on  their  respective  displays. 

•  Ability  to  address  and  manipulate  route  data  at  different  levels  of  granularity,  ranging  from  an  entire 
route  down  to  an  arbitrary  section  of  that  route. 

•  A  coherent  route  representation  schema  affording  an  orderly  protocol  for  addressing  both  entire 
routes  and  their  constituent  route  elements 

•  Coordination  (or  better  yet  -  integration)  of  these  visualization  innovations  with  other  WCSS 
capabilities  for  generating,  editing,  and  /  or  manipulating  route  specifications. 

•  An  improved  route  data  repository  (e.g.,  a  next-generation  F2  database)  reflecting  the  route 
representation  protocols  /  schemata  cited  in  the  previous  points 


Summary:  Our  WCD  Working  Criteria 

With  respect  to  direct  support  for  flight  planning,  the  primary  WCSS  design  criteria  can  be  summarized 
as  follows: 

•  A  flight  planning  WCSS  must  provide  a  coherent  visualization  platform  for  the  common  geo¬ 
context48  and  those  constraint  cues  associated  /  correlated  with  this  geo-context. 

•  To  promote  coherence  in  addressing  routes,  a  flight  planning  WCSS  must  provide  for  'multi-level’ 
route  referential ity  allowing  users  to  address  route  specifications  at  different  levels  of  granularity. 

•  To  address  team  members’  diverse  needs,  a  flight  planning  WCSS  must  provide: 

•  ‘dual-mode  ’  (graphical  /  textual)  route  display  and  manipulation 

•  automatic  correlation  /  updating  of  one  versus  the  other  (mode) 


48  The  term  'geo-context'  is  used  herein  to  denote  the  set  of  geo-spatial  elements,  dimensions,  etc.,  necessary  to  portray 
relevant  information  in  terms  of  geographical  or  spatial  correlates. 
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In  the  following  subsections  these  criteria  will  be  discussed  in  more  detail  and  in  the  order  in  which  they 
were  cited  above.  For  each  of  these  criteria,  we  shall  provide  a  deeper  discussion  of  each  criterion’s 
criticality  and  ramifications,  and  then  present  our  proposed  solution  to  meeting  them  in  the  context  of 
the  GAMAT  Phase  II  work.49 


Providing  a  Coherent  Visualization  Platform  for  Geo-Context 

As  stated  above,  the  primary  referential  (and  hence  visualization)  context  for  evaluating  flights  and  the 
constraints  affecting  them  is  a  geo-spatial  one.  A  flight  is  a  procedure  which  results  in  the  movement  of 
a  set  of  materiel  (i.e.,  an  aircraft,  its  crew,  its  cargo,  etc.)  from  a  geo-spatially  delineated  point  of 
departure  to  an  intended  point  of  arrival.50  Certainly,  there  are  elements  of  the  flight  that  can  be 
addressed  in  terms  other  than  the  geo-spatial  (e.g.,  fuel  bum  rates;  elapsed  times;  incidental  weather 
parameters  such  as  'headwind').  However,  it  is  the  geo-spatial  context  which  provides  the  referential 
background  against  which  the  largest  proportion  of  the  pertinent  aspects  of  a  flight  (during  and  with 
respect  to  its  execution  phase)  can  be  portrayed. 

The  candidates  for  such  'pertinent  aspects'  to  be  superimposed  atop  a  geo-spatial  background  are 
numerous.  There  are  a  variety  of  data  types  of  possible  relevance  to  be  fused  in  a  route  visualization,  and 
there  are  multiple  overlays  /  layers  within  each  type.  This  introduces  the  potential  for  problematical 
visual  complexity,  given  the  range  and  number  of  phenomena  which  impinge  on  the  viability  and 
success  of  a  single  given  flight.  A  sufficient  flight  visualization  platform  will  have  to  make  allowance 
for  the  full  range  of  these  numerous  relevant  elements.  An  efficient  flight  visualization  platform  will 
have  to  be  capable  of  readily  portraying  these  elements  and  allowing  users  to  manipulate  them  to  fit  the 
purpose  at  hand.  An  effective  flight  visualization  platform  will  have  to  accomplish  these  objectives  in  a 
fashion  which  allows  the  user  to  constructively  address  his  /  work  task  without  getting  caught  up  in  the 
mechanics  of  the  interface  itself. 

This  does  not,  however,  mean  that  everything  should  be  portrayed  at  once.  On  the  one  hand,  there  are 
many  different  roles  /  positions  within  TACC,  and  each  one  of  them  has  his  /  her  own  general  and 
incidental  needs  with  respect  to  which  elements  must  be  inspected  at  any  given  time.  On  the  other  hand, 
you  never  know  what’s  going  to  be  relevant  to  a  given  person  for  a  given  task.  This  means  that  a  usable 
flight  visualization  platform  needs  to  provide  for  flexibility  in  assembling  an  instance  of  a  display  from 
all  the  available  data  elements. 

In  other  words,  we  need  to  design  and  implement  our  flight  planning  WCSS  central  visualization 
component(s)  such  that: 

•  Users  are  offered  all  categories  of  overlay  /  layer  data. 


49  It  should  be  pointed  out  that  the  themes  and  criteria  discussed  here  do  not  terminate  or  become  obsolete  with  the  close  of 
the  GAMAT  Phase  II  project.  As  has  been  the  case  with  our  other  TACC  WCSS  projects,  these  results  will  be  carried 
forward  into  FY04  and  beyond  under  the  aegis  of  the  WIDE  program. 

50  To  use  the  original  WCSS  nomenclature  from  the  HISA  project,  this  unit  set  of  materiel  is  the  'package',  the  points  of 
arrival  /  departure  are  the  'ports',  and  the  multi-faceted  object  of  reference  for  the  procedure  is  the  'passage  /  en  route'. 
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•  Users  have  the  ability  to  mix  and  match  which  overlays  they  want  on-screen  at  a  given  time. 

•  Users  have  the  ability  to  organize  and  manipulate  the  overlays  /  layers  they  currently  employ. 

Using  Multi-Level  Route  Referentiality  to  Impose  Visual  Coherence 

To  implement  an  effective  flight  visualization  platform,  we  need  to  construct  and  apply  a  coherent  route 
element  reference  framework  meeting  two  general  criteria: 

•  The  framework  must  address  ‘composition’  interrelating  the  most  atomic  route  constituents  up 
through  composite  elements  (e.g.,  whole  routes). 

•  The  framework  must  be  ‘complete’  enough  to  provide  a  context  for  describing  and  outlining  the 
necessary  routing  specifications. 

It  is  tempting  to  oversimplify  the  concept  of  'route'  by  considering  it  'that  which  connects  point  A  and 
point  B.'  In  practice,  however,  the  routes  traversed  by  AMC  aircraft  are  neither  planned  nor  executed  as 
such  simple  A-to-B  progressions.  There  are  a  variety  of  things  which  'punctuate'  the  overall  route  into 
smaller  chunks  that  can  be  addressed  in  and  of  themselves  (e.g.,  waypoints;  organized  tracks;  entry  and 
exit  points;  and  the  like). 

Even  upon  cursory  inspection,  one  sees  that  routes  are  composite  entities  made  up  of  a  variety  of 
components,  and  that  there’s  an  implied  composition  hierarchy  pertaining  to  these  routes.  At  the 
foundation  of  this  implied  composition  hierarchy,  there's  the  ‘atomic’  element  of  a  geo-referenced  point 
(e.g.,  a  waypoint  defined  as  a  lat  /  long  specification).  The  ‘top-level’  element  is  of  course  the  entire 
route  from  departure  to  destination  (i.e.,  port-to-port).  This  much  is  pretty  straightforward. 

This  initial  binary  distinction  between  'points'  and  'routes'  was  the  basis  for  the  'double  level 
visualization'  concept  briefed  to  AMC  customers  and  SME's  beginning  in  late  summer  2003.  This 
concept  was  introduced  to  illustrate  our  proposal  that  a  more  effective  flight  visualization  interface 
would  permit  users  to  address  routes  in  more  than  one  way.  However,  a  closer  examination  of  the 
taxonomic  and  terminological  bases  for  everyday  practice  brought  to  light  a  considerably  higher  degree 
of  referential  complexity  than  this  cursory  distinction  would  imply. 


68 


Probing  and  Analyzing  Recognized  Route  Element  Nomenclature 

A  survey  of  relevant  aeronautical  terminology  was  conducted  in  2003  as  a  means  for  evaluating  the 
prospects  for  generating  the  sort  of  coherent  referential  framework  we  sought.  This  survey  was  done 
using  the  FAA's  CATS  database  -  arguably  the  single  most  authoritative  reference  point  for  aeronautical 
practice.  The  survey  was  done  by  running  multiple  searches  against  the  CATS  database,  each  search 
based  on  a  selected  keyword.51 

Each  of  these  searches  produced  large  sets  of  entries  from  the  CATS  database,  and  many  of  these  entries 
turned  up  in  multiple  of  the  searches.  The  search  results  were  collated  and  compiled  with  redundant 
entries  eliminated.  Some  other  entries  were  eliminated  on  the  basis  of  non-relevance  to  specifying  or 
describing  flight  routes.52  An  illustrative  sample  subset  of  the  compiled  listing  is  provided  in  Appendix 
A. 

In  the  middle  ground  between  these  atomic  and  overall  levels  of  reference  there  is  a  confusing  array  of 
candidate  elements,  not  all  of  which  dovetail  neatly  one  to  another.  There’s  a  variety  of  terminology 
employed  for  route  elements  in  this  middle  ground.  Some  of  this  terminology  is  peculiar  to  one  or 
another  organization  (e.g.,  AMC,  FAA).  Some  of  this  terminology  applies  to  only  one  or  another  phase 
of  the  flight  being  executed  (e.g.,  approach  legs).  It's  not  clear  that  this  nomenclature  sorts  itself  out 
into  neat  ‘stacking  categories’  which  we  could  readily  leverage  to  construct  a  coherent  taxonomy  to  be 
reflected  in  our  flight  visualization  WCSS. 


Categorizing  Existing  Route  Element  Terminology 

An  analysis  of  the  terminology  culled  from  the  FAA  resources  yielded  two  primary  criteria  for 

discriminating  among  terms  and  constructs: 

•  Spatial  /  Geometric  Scope.  The  concepts  /  terms  can  be  sorted  with  respect  to  the  geometric 
dimensionality  of  that  which  they  denote  (e.g.,  'points',  'lines',  'areas',  and  ’spaces'). 

•  Natural  /  Artificial  /  Functional  Context.  A  second  criterion  that  can  be  applied  has  to  do  with 
whether  the  construct  /  term  denote  something  apparent  in  the  'natural  world'  (e.g.,  shorelines)  versus 
something  abstract  projected  onto  the  natural  world  (e.g.,  political  boundaries;  navigational  fixes) 
versus  something  which  is  peculiar  to  a  flight  path  rather  than  the  'world'  it  traverses  (e.g.,  'final 
approach'). 


51  Examples  of  the  keywords  used  include:  airway,  route,  corridor,  segment,  region,  waypoint,  Pack,  path,  flyway,  sector, 
FIR,  airspace,  area,  and  zone. 

52  In  other  words,  some  'hits'  involved  terms  which  made  allusion  to  route  components,  but  were  not  themselves  concepts  for 
such  components. 
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No  other  taxonomic  criteria  were  found  which  met  the  critical  requirements  of  (a)  correlating 
terminology  onto  a  scheme  of  referential  relevance  to  either  the  work  and  /  or  the  elements  of  user 
interface  design;  and  (b)  being  of  sufficient  generality  to  encompass  the  range  of  terminology  obtained 
during  the  search. 

With  regard  to  the  first  sorting  criterion,  Table  1.6-1  illustrates  a  correlation  for  a  summary  set  of  terms 
culled  from  the  CATS  database  and  the  four  spatial  /  geometric  categories  listed  above.  A  brief  working 
description  is  given  for  each  of  the  four  categories  portrayed,  and  a  representative  set  of  example  terms 
is  provided.  The  set  of  examples  is  'representative'  because  multiple  entries  redundant  with  respect  to  a 
given  subclass  (e.g.,  'zones',  'fixes')  are  listed  under  the  subclass  identity  alone. 

The  spatial  /  geometric  'plot'  outlined  in  Table  1.6-1  is  of  particular  interest  in  WCSS  analysis  and 
design,  because  'geometry'  is  a  key  component  in  visualization  design,  and  appropriately  effective 
visualization  is  a  key  goal  of  work-centered  design.  As  it  turned  out,  this  spatial  sorting  provided  a 
'cleaner'  sort  than  other  candidates,  in  the  sense  that  it  addressed  the  most  terms  in  the  most  consistent 
and  coherent  fashion. 

Table  1.6-1:  Route  Element  Terminology  Correlated  with  Spatial  /  Geometric 

Categories 
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POINT 

Any  element  capable  of 
being  specified  with  respect 
to  a  single  locus  in  a 
coordinate  space  (e.g.,  lat  / 
long). 

•  Lat  /  Long 

•  Fix 

•  Reporting  point 

•  Significant  point 

•  Vertex 

•  Waypoint 

•  Intersection 

•  Approach  point 

•  Transition  point 

LINE 

Any  element  construed  as  a 
line  or  linear  progression 
connecting  at  least  two  end 
points. 

•  Path 

•  Route 

•  Centerline  for 
corridor 

•  Final  approach 

•  Track 

•  Flyway 

•  Segment 

•  Course 

AREA 

Any  element  delineated  in 
terms  of  spatial  extent  in  each 
of  two  dimensions. 

•  Area 

•  Airport 

•  Airway 

•  Sector 

•  Stopway 

•  Zone 

•  Aerodrome 

•  Corridor 

•  Clearway 

SPACE 

Any  element  delineated  in 
terms  of  spatial  extent  in 
three  dimensions. 

•  Airspace 

•  Control  sector 

•  FIR 

•  Track  structure 

•  Protected  airspace 

•  Surface  area 

•  Control  area 

•  Danger  area 

•  Airway  structure 

•  Prohibited  area 

•  Restricted  area 
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Still,  another  type  of  categorization  recommends  itself  as  at  least  a  secondary  basis  for  sorting  out  route 
nomenclature.  This  one  was  based  on  the  character  of  the  element  in  terms  of  two  interwoven  features. 
The  first  of  these  features  relates  to  whether  the  element  is  (a)  'natural'  (i.e.,  the  element  is,  or  is 
deterministically  correlated  with,  a  natural  feature  of  the  geo-space)  or  (b)  'artificial'  (i.e.,  the  element  is 
delineated  with  regard  to  an  abstract  or  otherwise  ascribed  reference  set).  This  'artificial'  case  is  further 
differentiable  into  two  subclasses.  The  first  consists  of  those  artificial  elements  correlated  with  geo¬ 
spatial  abstractions  (i.e.,  those  abstractions  which  can  be  correlated  with  geo-spatial  features).  The 
second  consists  of  those  artificial  elements  correlated  with  features  delineated  in  terms  of  flight 
parameters  or  functional  bases  (e.g.,  operationally-delineated  zones;  radius  of  feasible  flight  given  fuel 
load). 

This  second  categorization  scheme  is  illustrated  in  Table  1.6-2.  It  turns  out  to  be  not  as  comprehensive 
at  sorting  the  recognized  elements  as  the  geometric  one  illustrated  above.  Neither  does  it  uniquely 
partition  the  set  of  recognized  elements  as  cleanly  as  the  geometric  one.  Still,  this  scheme  lends  itself  to 
differentiating  those  elements  directly  projectable  onto  a  background  geographical  map  from  others 
whose  projections  rely  on  other  (perhaps  arbitrary)  criteria. 

Table  1.6-2:  Route  Element  Terminology  Plotted  with  Regard  to  Type  of  Reference 
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NATURAL 

(Geo-spatial) 

Any  element  explicitly 
denoting  a  natural  geo¬ 
spatial  feature  or  denoting 
something  uniquely 
correlated  with  a  natural 
geo-spatial  feature 

•  Lat  /  Long 

•  Fix 

•  Reporting  point 

•  Track 

•  Aerodrome 

•  Airport 

•  Runway 

•  Touchdown  zone 

•  Waypoint 

•  Intersection 

•  Approach  point 

•  Clearway 

•  Flight  Path  (as  a  track) 

ARTIFICIAL 

(Geo-spatial) 

Any  element  which 
denotes  an  abstract 
'overlay'  onto  the  natural 
geo-spatial  map,  but  which 
has  no  unique  correlation 
with  observable  natural 
forms  /  locations  /  items. 

•  Vertex 

•  Airspace 

•  Path 

•  Geographic  Area  of 
Concern 

•  Air  Defense 
Identification  Zone 
(ADIZ) 

•  Final  approach 

•  Advisory  Area 

•  Flyway 

•  Segment 

•  Airway 

•  Significant  point 

•  Direct  route  segments 

•  FIR 

•  Flight  Plan  Area 

ARTIFICIAL 

(Flight-space) 

Any  element  which 
denotes  an  abstract  referent 
that  primarily  correlates 
with  something  (e.g.) 
functionally  or 
procedurally  delineated 
with  regard  to  a  flight  / 
mission  and  not  to  the  geo¬ 
spatial  context. 

•  Composite  Route 
System 

•  Control  sector 

•  Course 

•  Route 

•  Terminal  Area 

•  Sector 

•  Stopway 

•  Touchdown 

•  Zone 

•  Transition 

•  Transition  point 

•  Corridor 

•  Clearway 

•  Flight  Path  (as  a 
course) 

•  Landing  Area 

•  Missed  Approach 

Point 
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Neither  of  these  sample  breakdowns  is  perfect.  Both,  however,  provide  clues  for  the  characteristics  best 
suited  for  delineating  a  schema  for  coherent  route  visualization.  The  geometric  breakdown  illustrates 
that  it  is  feasible  to  organize  the  pertinent  terms  so  as  to  reflect  a  composition  /  decomposition  hierarchy. 
This  is  an  important  feature  for  aiding  users  in  navigating  among  and  manipulating  potentially  very 
complex  display  options  and  data  presentations.  The  natural  versus  artificial  breakdown  is  sufficiently 
comprehensive  to  suggest  that  there  are  useful  distinctions  to  be  drawn  with  respect  to  category  types  (as 
contrasted  with  representational  form  as  was  the  case  with  the  geometric  approach). 

In  summary,  the  geometric  breakdown  provides  evidence  that  a  reasonably  coherent  schema  can  be 
specified  for  canonical  reference  items  in  addressing  routes.  The  second  breakdown,  in  conjunction 
with  other  clues  obtained  from  our  Phase  II  knowledge  acquisition  efforts,  provides  evidence  for  the 
particular  visualization  layers  to  be  offered  a  user  in  a  route  display.  Neither  of  the  above-cited 
breakdowns  is  complete  enough  to  use  as  a  design  feature  'as  is'. 

These  two  sets  of  clues  correspond  to  two  distinct  schemas  which  must  be  generated  in  the  course  of 
designing  a  WCSS  solution  for  visualizing  routes  and  providing  TACC  staff  with  the  sort  of  multi-level 
referentiality  our  team  proposed  in  Phase  II.  The  first  is  a  multi-level  schema  for  organizing  the 
canonical  components  of  a  route  element  nomenclature.  This  will  give  a  general  basis  for  coherently 
addressing  routes  at  all  levels  of  granularity  and  hence  the  basis  for  devising  interface  specifications. 
The  second  is  an  organizational  schema  for  the  classes  of  display  layers  to  be  provided  in  a  route 
visualization  WCSS.  This  schema  incorporates  the  basic  route  elements  outlined  in  the  first  schema  as 
the  implementation  details  for  how  to  portray  route  information  along  with  other  data  relevant  to 
decisions  on  what  route  is  or  should  be  specified  for  a  given  mission  or  set  of  missions. 

In  the  course  of  our  Phase  II  GAMAT  project  initial  versions  of  these  two  schemata  were  developed.  In 
the  following  subsections  we  shall  review  these  draft  schemata  in  more  detail.  Later  we  shall  review  the 
proposed  interface  designs  within  which  these  schemata  will  be  leveraged  and  employed. 


A  Multi-Level  Schema  for  Route  Elements 

The  first  task  is  to  lay  out  the  abstract  schema  covering  those  general  route  elements  we  shall 
acknowledge  in  our  subsequent  WCSS  designs  and  their  interrelationships.  This  schema  will  determine 
the  types  of  elements  and  their  correlation  within  whatever  display  layer  or  layers  our  flight 
visualization  WCSS  designs  assigns  them.  The  set  of  layers  within  which  they  will  appear  will  be  the 
subject  of  the  next  subsection. 

As  discussed  in  the  previous  section,  there’s  an  implied  composition  hierarchy  pertaining  to  routes.  In 
simplest  form,  this  composition  hierarchy  can  be  sketched  in  terms  of  two  extremes: 

•  The  ‘atomic’  route  element  is  a  geo-referenced  point  (e  g.,  a  waypoint  defined  as  a  lat  /  long 
specification). 

•  The  ‘top-level’  element  is  the  entire  route  from  departure  to  destination  (i.e.,  port-to-port). 
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This  simplistic  binary  distinction  does  not  capture  the  obvious  intermediate  level(s)  of  reference  at 
which  (e.g.)  flight  planners  address  and  /  or  manipulate  route  specifications.  Intermediate  items  (such  as 
arbitrary  sections  of  an  overall  route)  are  commonly  addressed,  analyzed,  and  modified  during  the 
planning  process.53  Some  examples  of  such  intermediate  route  components  (e.g.  North  Atlantic  Tracks) 
are  discrete  units  with  assigned  identifying  labels.  To  account  for  the  atomic  and  top-level  extremes  as 
well  as  intermediate  subsets,  the  schema  outlined  in  Table  1.6-3  was  developed. 

Table  1.6-3:  A  Schema  for  Logical  Route  Elements 
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ROUTE 
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•  A  named  /  labeled  segment  set 

•  In  simplest  form,  identical  to  a 
named  segment. 

•  In  complex  form,  an  arbitrary 
assemblage  of  named  and/or 
unnamed  segments 

SEGMENT  SET 

•  Any  contiguous  set  of  segments 
comprising  a  continuous  path 
specification 

•  May  consist  of  any  combination 
of  names  and  /  or  unnamed 
segments 

i  M . M3 . • 

SEGMENT 

•  - . — . • 

•  Two  points  and  the  implied  line 
connecting  them. 

•  The  minimal  depiction  of  a  route 
or  a  portion  of  a  route 

•  Unnamed  Segment 

• . - . • 

•  The  unnamed  segment  set  is  the 
default  case. 

•  Named  Segment 

IcjhbdM 

•  A  segment  which  is  discretely 
addressable  using  a  label  or  tag 

•  The  minimal  element  necessary 
to  describe  an  addressable  route 

POINT 

• 

•  Default:  Lat  /  Long 

•  Alternate:  Named  geo-location 

The  schema  presented  in  Table  1.6-3  includes  the  atomic  and  composite  extremes  discussed  earlier.  The 
smallest  element  of  reference  is  a  geo -referenced  point.  The  default  is  presumed  to  be  a  geographical 
point  specified  in  terms  of  lat  /  long  coordinates.  This  includes  any  point  capable  of  being  translated 
into  such  a  lat  /  long  specification.  The  highest-level  element  is  a  route  in  its  entirety  (i.e.,  end-to-end). 
In  between  these  two  levels  of  reference  the  schema  introduces  two  additional  levels  of  reference  and 
associated  constructs: 


53  Indeed,  it  was  with  reference  to  such  intermediate  'segments'  that  flight  planners  and  other  TACC  personnel  suggested 
there's  a  need  for  modular  coherent  route  manipulation  as  a  way  to  facilitate  route  specification  construction  and  modification 
with  less  effort  and  cognitive  burden  compared  to  the  current  textual  procedure. 
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•  Segment.  In  the  context  of  our  route  element  schema,  a  'segment'  is  any  pair  of  points  and  the 
implied  line  connecting  them.54  The  specification  for  a  segment  should  include  a  pair  of  point 
specifications  (e.g.,  lat  /  long  or  equivalent  specifiers).  The  presumptive  connecting  line  (or  path)  is 
an  artifact  specified  by  its  end  points.  In  actual  TACC  practice,  however,  there  are  'segments'  which 
are  addressable  in  terms  of  a  label  or  tag  (e.g..  North  Atlantic  Tracks).  For  this  reason,  the  schema 
makes  provision  for  'unnamed'  (generic)  segments  and  'named'  (labeled)  ones.  Named  segments  are 
graphically  distinguished  by  an  enclosing  border. 

•  Segment  Set.  A  'segment  set'  is  any  contiguous  series  of  segments  specifying  a  continuous  path  or 
track.  A  segment  set  can  consist  of  any  combination  of  unnamed  and  /  or  named  segments.  A 
segment  set  can  be  of  arbitrary  length.  The  graphical  representation  of  a  segment  set  preserves  the 
visual  distinctions  made  between  named  and  unnamed  segments,  thus  cueing  the  user  as  to  which  is 
which. 


In  this  schema,  a  'route'  is  characterized  as  a  named  segment  set.  A  'complete  sortie  route'  would  then  be 
a  particular  instance  in  which  the  terminal  points  at  each  end  correspond  (a)  to  airfields  and  (b)  to  those 
particular  airfields  designated  as  the  departure  and  arrival  extrema  for  the  given  sortie. 

This  definition  leads  to  a  fairly  obvious  question.  One  might  well  ask  if  there  should  be  a  'named 
segment  set'  which  is  something  less  than  a  'complete  route'.  Owing  to  the  flexibility  with  which  the 
elements  can  be  combined,  such  an  intervening  candidate  element  is  considered  unnecessary.  Should 
there  be  generated  a  discrete  segment  set  amenable  to  subsequent  re-use,  it  should  be  capable  of  being 
assigned  a  label  and  'merged'  into  a  named  segment  set  available  for  future  reference.  This  presumptive 
capability  essentially  negates  the  criticality  of  introducing  a  'named  segment  set'  and  further 
complicating  the  schema.55 


A  Multi-Layer  Schema  for  Route  Visualization 

The  second  task  is  to  lay  out  the  schema  specifying  the  canonical  set  of  display  layers  needed  to 
comprise  a  useful  route  visualization  WCSS  and  the  criteria  for  their  default  ordering.  In  the  WCSS- 
GWM,  a  number  of  candidate  data  layers  were  made  available  for  WX  staffers'  selection,  inclusion,  and 
relative  ordering.  Originally,  these  layers  were  uniformly  representative  of  meteorological  phenomena 
or  data.  In  addition  to  these  weather  layers,  additional  graphical  strata  were  added.  One  such  stratum 
contained  geo-referenced  artifacts  representing  areas  of  concern  (e.g.,  alert  areas;  exclusion  zones) 
projected  onto  the  basic  geographical  context.  Another  such  stratum  depicted  routes  to  allow  WX 
staffers  to  evaluate  where  current  and  /  or  prospective  missions  might  be. 


54  This  corresponds  to  the  way  the  term  'segment'  is  used  in  (e.g.)  FAA  nomenclature. 

55  This  is  not  to  say  that  the  notion  of  a  'named  segment  set'  is  ruled  out.  The  schema  has  been  defined  to  permit  essentially 
unlimited  modularity  of  reference  and  flexibility  of  composition.  As  initially  defined  here,  the  schema  can  be  seen  as 
imposing  a  4-level  (point-segment-segment  set-route)  organization.  Changing  this  to  a  5-level  organization  through  insertion 
of  a  named  segment  set  class  is  a  straightforward  extension  that  can  be  readily  done  should  it  subsequently  be  decided  such  a 
move  would  be  useful. 
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By  and  large,  the  WCSS-GWM  provided  multiple  types  of  representations  as  layers,  but  didn't  subdivide 
these  layers  into  subsidiary  classes  (e.g.,  a  class  of  WX  layers  versus  a  class  of  route  layers).  The 
general  flight  visualization  capabilities  we  are  discussing  here  will  necessitate  allowance  for  a 
potentially  much  larger  population  of  available  data,  and  hence  a  larger  set  of  available  layers  to  be 
mixed  and  matched  on-screen.  For  the  sake  of  consistency  and  coherence  in  design,  we  need  to  generate 
a  schema  for  categorizing  candidate  layers  in  terms  of  logical  classes.  This  schema  must  include  a 
tractable  number  of  categories  within  which  all  prospective  display  layer  types  can  be  reasonably 
subsumed.  Given  the  diversity  of  data  already  demonstrated  to  be  useful  (e.g.,  in  our  GAMAT  project) 
considerable  thought  had  to  be  invested  in  negotiating  the  trade  offs  between  minimal  number  of 
categories  and  potentially  large  numbers  of  data  types.  As  of  the  close  of  our  Phase  II  effort,  the  draft 
layer  categorization  schema  had  evolved  into  the  5-level  layout  illustrated  in  Table  1.6-4. 

Table  1.6-4:  A  Schema  for  Route  Visualization  Layers 


§;>  y;:' 

..  v  ■  ■  . 

ROUTE  LAYER 

Flight  routing  display  elements. 

•  The  route  display  elements 
defined  in  our  earlier 
schema 

WX  LAYER 

Meteorological  display  elements 
(both  literal  and  abstracted  weather 
data). 

•  Any  of  the  WX  data 
components  currently 
displayed  in  the  GWM- 
WCSS 

•  WX-specific  watch  areas 

OPS-ARTIFACTS 

(ops-related  ‘fictions’) 

Artificial  /  synthetic  geo-referenced 
elements  specific  to  TACC  /  USAF 
ops 

•  Theater  delimitations 

•  No-fly  zones 

•  AOR’s 

GEO-ARTIFACTS 

(geo-related  ‘fictions’) 

Artificial  /  synthetic  geo-referenced 
elements  NOT  specific  to  TACC  / 
USAF  ops 

•  Geopolitical  areas 

•  Territorial  zones 

•  FIR  boundaries 

GEO¬ 

BACKGROUND 

(basic  spatial  context) 

Fundamental  geographic  elements 
correlating  with  physical  features  of 
the  earth. 

•  Specific  geo-points 

•  Land  /  sea  /  physical 
features 

Table  1.6-4  illustrates  the  five  canonical  layer  classes  in  play  as  of  the  end  of  our  Phase  II  project. 

These  classes  are  ordered  from  top  to  bottom  in  the  table  to  reflect  their  presumptive  or  default  on¬ 
screen  ordering.  The  topmost  layer  class  is  presumptively  'foreground',  and  the  bottommost  layer  class 
is  presumptively  'background'.  The  specific  order  illustrated  in  Table  1 .6-4  was  developed  on  the  basis 
of  multiple  factors,  including: 

•  Temporal  persistence.  Those  layers  representing  elements  that  are  relatively  transient  or  mutable  are 
positioned  toward  the  'foreground',  while  those  that  are  relatively  fixed  or  persistent  are  positioned 
toward  the  'background'. 


•  Manipulability.  The  reason  the  Route  Layer  is  presumptively  'foreground'  is  that  a  route  (as  an 
object  of  reference)  is  the  primary  type  of  representation  subject  to  manipulation  by  a  user.56 


56  This  claim  is  made  in  the  specific  context  of  a  tool  for  flight  /  route  visualization. 
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Conversely,  the  Geo-Background  Layer  is  presumptively  'background'  because  the  geo-spatial  or 
physical  context  is  the  one  least  amenable  to  manipulation. 


•  Distinguishing  'Natural'  versus  'Artificial'  Elements  of  Reference.  All  the  route  elements  identified 
in  the  CATS  database  search  are  explicitly  geo-referenced,  or  readily  capable  of  being  correlated 
with  geo-spatial  coordinates.  However,  there's  an  important  distinction  that  this  geographical 
commonality  obscures.  Some  of  the  route  elements  are  clearly  artifacts  defined  with  respect  to  (e.g., 
USAF)  operations  and  are  best  considered  as  abstractions  projected  onto  the  geo-space.  In  addition 
to  being  defined  operationally,  these  abstractions  are  often  of  the  most  immediate  operational 
consequence.  To  reflect  this  distinction,  ops-specific  and  geo-specific  artifacts  were  separated  into 
two  different  classes.57  Of  the  two,  ops-specific  constructs  were  considered  more  likely  to  be 
'foreground'  (cf.  above-cited  factors)  than  the  geo-specific  constructs. 


Dual-Mode  Route  Display  and  Automatic  Inter-Modal  Correlation 

It’s  clear  that  geo-spatial  visualization  would  aid  the  various  roles  in  addressing  routes.  It’s  also  clear 
that  textual  details  (e.g.,  waypoints;  entry  /  exit  times)  are  material  to  defining  feasibly  executable 
routes.  It’s  clear  from  our  KA  results  in  Phase  II  and  previous  years  that  TACC  staffers  may  use  both  of 
these  representational  and  reference  modes  to  address  and  engage  their  work  subject  matter. 

As  a  result,  it  is  a  straightforward  conclusion  that  our  WCSS  designs  for  general  flight  /  route 
visualization  aiding  will  have  to  reflect  the  following: 

•  The  WCSS  design  concepts  must  provide  for  display  of  both  graphical  and  textual  data.  Graphic 
representations  hold  the  greater  promise  for  affording  TACC  users  overview  information  that  is  easy 
to  grasp  (in  general  terms)  and  quick  to  absorb.  On  the  other  hand,  textual  data  is  the  better  choice 
for  supplying  users  with  details  (e.g.,  lat  /  long  specifications)  for  elements  displayed  graphically. 


•  The  graphic  and  textual  displays  must  be  linked  /  correlated  as  to  what  they  ’re  showing  the  user  at 
any  given  moment.  In  other  words,  the  WCSS  route  visualization  display(s)  must  be  capable  of 
presenting  the  user  with  corresponding  and  correlated  data  of  both  types  upon  initial  invocation.  For 
example,  the  WCSS  should  provide  on-screen  display  of  both  the  graphical  view  on  a  given  route 
and  the  text  containing  its  details.  Selecting  a  discrete  route  on  the  graphical  display  should  (e.g.) 
automatically  populate  the  associated  text  display  with  the  data  for  that  selection.  Conversely, 
bringing  up  the  text  summary  on  a  particular  mission  /  flight  could  automatically  highlight  that  same 
item  on  the  graphical  map  display.  In  this  way  we  can  design  the  WCSS  such  that  the  user's  focus  is 
highlighted  across  data  /  display  modalities.^8 


57  Another  reason  for  segregating  out  the  operationally-delineated  elements  is  that  these  are  subject  to  being  relevant  and  /  or 
persistent  based  on  the  purpose  at  hand.  One  can  easily  conceive  of  a  situation  in  which  a  planner  or  execution  staffer  might 
want  to  look  at  the  geo-space  in  terms  of  distinct  operational  parameters  (e.g.,  ATC  versus  USAF  versus  naval  'zones  of 
concern’). 

58  The  objective,  of  course,  is  to  reduce  cognitive  burdens  imposed  when  a  user  must  spend  additional  time  and  effort 
locating  data  under  one  modality  which  is  associated  with  an  object  of  reference  addressed  within  the  other  modality.  For 
example,  let’s  say  there  are  two  display  elements  affording  the  user  graphical  and  textual  information  on  a  set  of  missions 
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•  The  data  within  these  displays  must  be  cross-correlated  so  that  updating  /  changing  one 
automatically  updates  the  other.  For  the  sake  of  clarity,  we  must  point  out  that  the  correlation  / 
correspondence  mandated  in  the  foregoing  point  (about  initial  invocation)  must  carry  forward  as 
dynamic  changes  occur  in  the  underlying  data  or  in  the  state  of  the  display  as  induced  by  the  user 
(e.g.,  when  the  user  manipulates  an  on-screen  graphic  element  to  simulate  a  route  change).  In  other 
words,  we  mean  to  imply  an  intent  to  implement  on-screen  cross-correlation  for  active  manipulations 
of  data  (beyond  ‘passive’  viewing  of  the  data).  This  cross-correlation  will  permit  agents  to  update 
either  of  the  displays  (graphical  or  textual)  in  response  to  changes  made  on  the  other.  This  dynamic 
coordination  will  permit  planners  to  see  and  evaluate  the  effects  of  changes  made  in  either  mode. 


•  The  allocation  of  graphic  and  textual  data  within  and  /  or  among  on-screen  WCSS  displays  must  be 
consistent  and  understandable.  There  are  multiple  ways  in  which  graphical  and  textual  data  can  be 
associated  on-screen.  One  approach  is  to  provide  (e.g.)  graphical  maps  and  give  the  user  the  ability 
to  rapidly  invoke  the  other  data  type  (e.g.,  text  details  about  a  point  on  the  map)  as  he  /  she  sees  fit. 
Another  approach  is  to  provide  multiple  on-screen  display  elements,  one  for  each  of  the  data  types 
(e.g.,  a  map  palette  with  a  separate  structured  textual  palette  displaying  detailed  data  for  a  graphical 
object  selected  on  the  map).  Whether  we  choose  one  or  more  tactics  in  our  WCSS  designs,  we  must 
be  consistent  in  our  overall  approach. 


The  Flight  Visualization  Tool  (FVT):  Introduction 

The  central  component  of  our  redesigned  WCSS  toolkit  is  a  geo-spatial  visualization  aid  allowing 
TACC  team  members  to  efficiently  and  effectively  review  route  information  in  a  manner  closely 
reflective  of  the  actual  flight  being  (or  to  be)  executed.  Broadly  speaking,  this  aid  will  incorporate  many 
of  the  features  first  prototyped  and  demonstrated  with  regard  to  weather  functions  during  Phase  I  and 
Phase  II  of  the  GAMAT  project.  Like  the  WCSS-GWM,  this  aid  will  highlight  a  central  graphic  map 
display.  Like  the  WCSS-GWM,  this  aid  will  provide  its  users  with  a  comprehensive  set  of  overlay 
layers  which  can  be  mixed  and  matched  to  suit  that  user's  particular  needs.  The  label  we  created  for  this 
general  visualization  aid  is  the  Flight  Visualization  Tool  (FVT). 

Although  both  WCSS  concepts  employ  a  central  geo-spatial  display,  the  FVT  differs  substantially  from 
the  earlier  WCSS-GWM.  The  most  important  such  difference  concerns  the  degree  to  which  each  of 
these  WCSS  concepts  is  intended  to  serve  as  either  a  standalone  application  or  an  integral  component  of 
a  larger  suite.  The  WCSS-GWM  was  designed  to  be  a  tool  primarily  aimed  at  visualizing  weather 
phenomena.  The  function  of  generating  new  work  products  was  a  relatively  limited  one  in  the  case  of 
weather,  consisting  mainly  of  generating  weather  charts.  These  potential  output  products  were  mainly 
framed  in  the  same  manner  as  the  visualization  itself  (i.e.,  geo-referenced  graphics). 


(designated  missions  A  through  J).  If  the  user  selects  mission  F  in  either  of  the  display  modalities,  we  can  minimize  his  /  her 
cognitive  burden  by  automatically  highlighting  the  representation  of  mission  F  under  the  other  modality. 
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These  characteristics  don't  carry  over  to  the  FVT.  Mission  and  flight  planners  must  employ  and  produce 
a  wider  range  of  information  artifacts,  most  of  which  are  not  of  the  same  (graphical  /  geo-referenced) 
species  as  the  visualization  features  we  propose  for  the  FVT.  For  the  most  part,  these  are  textual 
artifacts,  and  their  processing  is  a  matter  of  text  editing.  As  such,  an  FVT  is  less  amenable  to  direct 
incorporation  and  /  or  generation  of  flight  planning  work  products  (e.g.,  a  textual  route  specification 
document)  than  was  the  case  for  the  WCSS-GWM  and  (e.g.)  weather  charts.  As  a  result,  the  FVT  is 
intended  to  serve  as  one  among  many  WCSS  tools  within  an  overall  suite  -  a  deployment  and  use 
context  considerably  different  than  was  the  case  for  the  WCSS-GWM. 

This  means  that  the  FVT  has  to  make  provision  for  coordination  with  other  'outboard'  tools.  Some  of 
these  outboard  aids  may  be  read-only  information  retrieval  mechanisms  (e.g.,  a  Form  59  display). 
Others  will  necessarily  be  interactive  palettes  within  which  textual  flight  specifications  are  both 
displayed  and  /  or  edited.  This  in  turn  means  that  the  FVT  design  has  to  make  provision  for: 

•  Easy  invocation  of  relevant  outboard  information  displays  and  tools 

•  Coordination  of  on-screen  display  characteristics  (e.g.,  foregrounding)  relative  to  these  outboard  aids 

•  Sharing  (e.g.,  mirroring)  of  specific  data  between  the  central  FVT  and  the  outboard  aids 

•  Coordination  of  data  states  (e.g.,  cross-correlated  updates)  between  the  FVT  and  the  outboard  aids 

•  An  ability  to  disengage  such  cross-correlation  should  the  user  desire  to  explore  a  'what-if  scenario 
(e.g.,  on  the  FVT  display)  without  automatically  recording  the  states  of  this  exploration  (e.g.,  until  a 
final  decision  is  made) 


Allowing  for  these  capabilities  will  require  that  the  FVT  include  design  features  above  and  beyond  those 
represented  by  the  earlier  WCSS-GWM.  There  must  be  controls  allowing  the  invocation  of  outboard 
aids.  There  must  also  be  mechanisms  for  cueing  the  user  as  to  which  aids  are  available  or  active  at  any 
given  time.  Provision  has  to  be  made  on  the  FVT  itself  for  displaying  any  data  shared  with  a  given 
outboard  aid. 

The  intended  generality  of  the  FVT  as  a  visualization  tool  means  that  it  will  display  a  variety  of 
selectable  elements  on  which  a  user  should  be  capable  of  'drilling  down’.  The  appropriate  or  feasible 
outboard  information  aids  and  tools  will  need  to  be  made  context-specific  with  regard  to  which  type  of 
on-screen  element  is  being  prioritized.  For  example,  invocation  of  a  Form  59  is  a  reasonable  action 
when  one  is  focusing  on  a  given  mission  being  displayed  on  the  central  map  visualization.  However,  a 
Form  59  is  a  nonsensical  option  to  offer  someone  in  the  context  of  a  selected  airfield  or  national  entity. 
Such  nuanced  contextual  distinctions  add  complexity  to  the  design  requirements  for  such  a  general 
purpose  tool  as  the  FVT  is  proposed  to  be. 
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Another  way  in  which  the  FVT  differs  from  the  WCSS-GWM  lies  in  the  scope  and  number  of  potential 
data  layers  for  which  its  design  must  provide.  As  a  tool  focused  on  weather  phenomena,  the  WCSS- 
GWM  needed  to  encompass  a  range  of  overlay  data  categories  circumscribed  by  available  weather  data 
assets.  During  the  course  of  the  GAMAT  projects,  this  basic  meteorological  repertoire  was  augmented 
with  route  depictions.  As  a  more  generic  display  tool,  the  FVT  must  be  capable  of  handling  a 
potentially  greater  number  of  such  overlays.  This  means  that  visual  complexity  will  almost  certainly  be 
an  even  bigger  issue  with  the  FVT  as  it  was  with  the  WCSS-GWM.  It  also  means  that  layer 
management  options  and  controls  need  to  be  streamlined  in  the  FVT  to  avoid  overloading  the  user’s 
ability  to  understand  and  employ  them. 


The  Flight  Visualization  Tool  (FVT)  Concept 

During  the  last  months  of  the  GAMAT  Phase  II  project  a  conceptual  prototype  for  a  Flight  Visualization 
Tool  (FVT)  was  developed  and  briefed.  This  initial  concept  was  generated  as  a  variation  on  the  WCSS- 
GWM  prototype  design.  The  main  feature  carried  forward  from  the  WCSS-GWM  is  a  central  geo- 
referenced  display  with  flexible  capabilities  for  composing  the  optimal  multi-layered  visualization  for 
the  work  at  hand.  In  addition,  the  longstanding  WCSS  principles  of  'centralized  visualization'  and 
'peripheral  control'  guided  the  FVT  design.  In  the  following  subsections  we  shall  introduce  and  discuss 
the  elements  of  this  FVT  concept.  The  general  form  of  this  initial  FVT  concept  is  illustrated  in  Figure 
1.6-1. 


79 


Geo-visualization  Controls/Tools 


Information 

Display 


Figure  1.6-1:  Flight  Visualization  Tool  (FVT)  Concept 


As  shown  in  Figure  1.6-1,  the  FVT  design  concept  is  arranged  in  accordance  with  the  WCD  principles 
of 'central  visualization  /  peripheral  control'.  In  the  center  is  the  graphic  representation  of  a  geographical 
space,  atop  which  are  arranged  user-selectable  'layers'  for  a  variety  of  features  and  factors.  Above  this 
central  visualization  panel  are  the  basic  controls  and  tools  for  manipulating  the  general  geo-spatial 
display  content.  To  the  left  of  the  central  display  element  are  the  layer  controls  and  tools.  These  are 
grouped  together  to  provide  composite  all-in-one  cueing  and  control  over  the  layers  a  given  user  has 
(and  /  or  may  have)  superimposed  on  the  geo-spatial  background  in  the  central  display.  To  the  right  of 
the  central  display  element  are  two  new  elements.  The  upper  is  a  composite  display  element  providing 
auxiliary  textual  information  to  the  user.  The  lower  is  a  composite  set  of  selection  options  through 
which  the  user  may  select  and  invoke  additional  ('outboard')  WCSS  tools.  In  the  following  subsections 
we  shall  discuss  these  subsidiary  components  of  the  FVT  design  concept  in  more  detail. 


Geo-  Visualization  Display 

The  central  visualization  is  a  geographical  map  upon  which  route,  weather,  and/or  other  relevant  data 
elements  may  be  layered.  With  regard  to  the  GAMAT  Phase  II  emphasis  on  flight  planning,  the  most 
important  such  elements  are  those  that  relate  to  routes.  The  FVT  concept  is  intended  to  permit  modular 
overlays  of  routes,  sets  of  routes,  and  subsidiary  elements  of  an  individual  route  (as  needed),  affording 
the  user(s)  the  ability  to  correlate  and  evaluate  one  or  more  routes  with  respect  to  the  geo-spatial  context. 
Grounding  the  display  in  a  geographical  context  permits  the  addition  and  correlation  of  additional  geo- 
referenced  overlays  (e.g.,  weather  data,  exclusion  zones,  etc.). 

Employed  as  a  summary  overview  (e.g.,  as  a  team  display  up  on  the  wall),  this  geo-spatial  foundation 
allows  the  FVT  to  be  employed  as  a  team  or  supervisory  tool  to  maintain  situation  awareness  with 
respect  to  all  flights  traversing  a  given  region.  In  this  respect,  the  FVT  represents  a  generalization  of  our 
prior  GAMAT  visualization  capabilities  toward  multiple  uses  and  collaborative  support  (cf.  Chapter 
1.3). 

Employed  on  a  single  workstation  (e.g.,  by  a  flight  planner),  the  FVT  similarly  provides  the  basic 
display  capabilities  necessary  to  permit  a  planner  to  review  one  or  more  routes  (and,  e.g.,  evaluate  their 
geographical  range(s))  or  to  review  a  given  geographical  expanse  (and,  e.g.,  evaluate  what  flights  are 
traversing  it).  Particularly  when  used  by  an  individual  flight  planner,  the  FVT  concept  is  intended  to 
extend  beyond  a  passive  visualization  aid.  It  is  intended  to  also  provide  an  interactive  tool  for 
generating  and  manipulating  route  depictions  in  the  course  of  the  planning  process. 

This  dynamic  /  interactive  aspect  of  the  FVT  concept  is  to  be  implemented  so  as  to  provide  for: 

•  Direct  importation  and  display  of  routes  based  on  data  from  other  TACC  assets  (most  particularly 
ACFP) 

•  Direct  manipulation  of  ACFP  routes  on  the  FVT  map  display 

•  The  ability  to  select  a  route  (or  a  segment  of  a  route)  via  common  “point  and  click”  tactics 

•  The  ability  to  implement  route  modification(s)  via  “grab  and  drag”  tactics 
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•  The  ability  to  immediately  see  the  effects  of  direct  manipulation  in  terms  of  updated  route 
parameters  (as  displayed  in  the  auxiliary  information  displays  and  /  or  outboard  palettes)59 


By  shifting  the  primary  flight  planning  modality  from  free-form  text  editing  to  contextually-constrained 
visual  editing,  the  FVT  concept  is  designed  to: 

•  Minimize  the  cognitive  burden  of  imagining  a  route  based  on  a  purely  textual  description 

•  Increase  the  number  of  (geo-spatial)  cues  that  the  planner  may  readily  correlate  with  a  depicted  route 

•  Increase  the  probability  of  the  planner's  recognizing  constraints,  opportunities,  etc.,  based  on  this 
increased  cueing 

•  Minimize  the  risk  of  planners  overlooking  obvious  opportunities,  conflicts,  constraints 

•  Minimize  the  risk  of  procedural  and  conceptual  digressions  by  providing  geo-correlated  feedback  on 
route  manipulations 


Geo-  Visualization  Controls  /  Tools 

These  are  the  general  display  controls  grouped  together  and  positioned  above  the  central  display 
window.  This  set  of  elements  provides  the  user  with  the  means  to  manipulate  the  central  geo¬ 
visualization  display  itself  and  to  select  /  manipulate  areas  or  objects  on  that  display  using  direct 
manipulation  techniques.  The  proposed  layout  of  this  component's  elements  is  illustrated  in  Figure  1.6- 
2. 
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Figure  1.6-2:  FVT  Geo-Visualization  Controls  /  Tools 
(Not  to  Scale) 
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The  specific  elements  subsumed  in  the  geo-visualization  control  /  tool  set  include: 
•  Left  /  Right  buttons  (on  ends)  permit  rapid  shifting  of  map  frame  laterally. 


59  Full  illustration  of  this  interplay  between  the  FVT  and  the  outboard  palette(s)  will  have  to  be  deferred  until  a  representative 
such  palette  (the  Flight  Planning  Palette)  is  introduced  later  in  this  chapter. 
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•  Multi-directional  ‘nudge’  buttons  permit  incremental  shifting  of  current  map  image  in  8  directions. 

•  Zoom  buttons  (magnifying  glass  icons)  permit  reduction  /  magnification  of  current  map  image  with 
current  center  point. 

•  ‘Arrow  tool’  (default)  designates  cursor  as  selection  implement. 

•  ‘Marquee  tool’  allows  user  to  designate  a  rectangularly-delineated  set  of  elements  (within  the 
topmost  display  layer). 

•  ‘Lariat  tool’  allows  user  to  designate  an  arbitrarily-delineated  set  of  elements  within  the  topmost 
display  layer. 

•  ‘Crosshairs  tool’  allows  user  to  designate  a  point  around  which  to  re-center  the  map  display. 


Layer  Display  /  Controls 

The  'value  added'  to  the  central  geographical  display  lies  in  the  various  layers  which  can  be  flexibly 
invoked  and  arranged  for  overlay  atop  the  basic  map.  The  map  alone  is  not  all  that  informative.  What 
makes  it  informative  in  the  context  of  the  work  (e.g.,  the  flight  planning  tasks)  is  the  ability  of  that 
geographical  context  to  interrelate  the  diverse  elements  (e.g.,  weather,  route  specifications,  airfields) 
comprising  the  critical  aspects  of  the  work  activity's  decision  making  processes.  As  such,  the  Layer  / 
Display  Controls  component  of  the  FVT  is  more  than  simply  a  graphic  display  controller.  It  is  in  effect 
the  primary  means  by  which  the  user  fuses  multiple  data  objects  into  relevant  'information'.  Phrased 
another  way,  the  layering  tactics  provide  direct  aiding  for  'sense  making'  within  the  extremely  complex 
decision  space  of  flight  planners  and  other  members  of  the  TACC  team. 

This  means  that  the  Layer  /  Display  Controls  must  be  capable  of  both  (a)  addressing  the  potential 
complexity  of  the  multiple  data  types  employed  and  their  interrelationships  as  well  as  (b)  affording  the 
user  the  simplest  and  most  direct  possible  tactics  for  grappling  with  this  complex  data  set.  This  in  turn 
means  that  the  design  of  this  FVT  component  must  provide  the  user  maximum  cueing  and  manipulation 
with  minimum  visual  and  procedural  complications.  The  WCSS  concept  for  this  subsidiary  FVT 
function  is  illustrated  in  Figure  1.6-3. 

The  basic  features  of  the  form  and  layout  of  the  Layer  /  Display  Controls  component  include: 

•  Listing  of  available  layer  sets  as  discrete  composite  units60 

•  Within  each  layer  set,  an  enumerated  list  of  available  layers 


60  The  term  'layer  set'  is  used  here  to  denote  a  collection  of  layers  grouped  according  to  taxonomic  affiliation.  The  set  of 
layer  sets  employed  in  the  FVT  is  intended  to  reflect  the  categorization  schema  outlined  earlier  in  Chapter  1 .6. 
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•  Arrows  /  markers  denoting  layer  set  display  state  -  i.e.,  ‘collapsed  versus  expanded’. 61 

•  Color  coding  for  each  layer  set  /  layer  entry  such  that  (e.g.): 

•  Gray  /  White  =  Inactive;  Color  =  Active62 

•  Green  =  Active  /  Status  OK;  Red  =  Active  /  Alert  Noted63 


“Pop-down’ 
dynamic 
telescoping  of ' 
layer  sets  and 


‘Gray-out’  color 
coding  to  indicate 
deactivated  layers 


I .  !#• 


Color  coding  of 
^  layer  index 
elements  to 
indicate  alert 
status  (e.g.  red  to 
cue  an  alert 
condition  portrayed 
in  a  given  WX 


(FOREGROUND) 


‘Gray-out’  color 
coding  to  indicate 
deactivated  layers 


(BACKGROUND) 


Figure  1.6-3:  FVT  Layer  Display  /  Controls 


(Not  to  Scale) 


61  In  other  words,  a  ’collapsed’  layer  set  is  designated  by  the  layer  set  label  /  tag  alone.  An  ’expanded’  layer  set  is  comprised 
of  the  category  (layer  set)  designator  plus  the  indexes  /  tags  for  each  of  the  subsidiary  layers  in  that  set. 

62  This  part  of  the  color  coding  cues  the  user  on  the  pragmatics  of  FVT  state  (i.e.,  which  layers  are  ’in  play’  at  any  given 
moment). 

6’  This  part  of  the  color  coding  cues  the  user  on  the  relevant  status  of  the  work  subject  matter  (e.g.,  routes  and  constraints  on 
routes)  as  correlated  with  the  layer(s)  to  which  he  /  she  should  direct  attention  for  further  assessment. 
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As  illustrated  in  Figure  1.6-3,  the  vertical  ordering  of  the  layer  set  /  layer  indicators  is  designed  to 
actively  cue  the  user  on  the  ordering  of  said  layers  on  the  central  geographical  display.  Those  layers  at 
or  near  the  top  of  the  vertical  listing  correspond  to  the  'foreground',  and  those  at  or  near  the  bottom 
correspond  to  the  'background'  relative  to  the  map  display.  These  layer  and  layer  set  indexes  /  tags  are 
not  fixed  in  position.  They  can  be  moved  upward  and  downward  (as  described  below)  to  reflect  the 
particular  ordering  of  the  geo-visualization  layers  in  the  center  of  the  FVT. 

Finally,  these  layer  indicators  are  intended  to  function  as  interactive  'handles'  allowing  the  user  to 
directly  manipulate  the  geo-display  to  suit  his  /  her  requirements.  The  specific  tactics  prescribed  so  far 
for  such  manipulations  are  as  follows: 

•  Each  layer  set  tab  can  be  ‘grabbed  and  dragged’  (mouse-over  +  button  hold  +  drag)  up  or  down  to 
rearrange  relative  ‘vertical’  ordering  of  the  sets.64 

•  Each  layer  tab  can  be  X-clicked  (X  =  right  or  left  or  double)  to  pop  up  layer  control  /  preferences 
widgets.65 

•  Each  layer  set  /  layer  tab  can  be  Y-clicked  (Y  =  option  other  than  X)  to  toggle  that  element  between 
‘active’  and  ‘inactive’  state.66 


Through  combining  and  simplifying  the  layer  display  and  control  features  (relative  to  the  WCSS- 
GWM),  the  FVT  WCSS  concept  affords  the  user  an  even  greater  degree  of  direct  aiding  and  control  than 
even  that  well-accepted  design  provided.  This  streamlining  of  layer  features  is  necessary  to  minimize 
the  cognitive  burdens  and  maximize  the  situation  awareness-facilitating  functions  this  component  of  the 
FVT  is  intended  to  perform. 


Auxiliary  Information  Displays 

In  the  upper  right  comer  of  the  FVT  design  concept  we  have  provided  certain  additional  data  displays  to 
afford  the  user  additional  information.  This  additional  information  is  needed  to  (a)  notify  the  user  of 
certain  background  data  of  global  relevance;  (b)  cue  the  user  as  to  what  he  /  she  has  selected  as  being  of 
most  immediate  interest  on  the  central  geo-visualization  display;  and  (c)  provide  summary  cueing  data 
on  that  selection.  The  initial  design  concept  incorporates  three  subsidiary  components  of  this  auxiliary 
information  presentation,  each  corresponding  to  one  of  the  points  cited.  The  arrangement  of  this  set  of 
components  is  illustrated  in  Figure  1 .6-4. 


64  Such  direct  manipulation  of  the  layer  'tag'  vertical  ordering  is  intended  to  result  in  an  immediate  corresponding  change  in 
the  background-to-foreground  ordering  of  the  layered  graphic  data  on  the  central  geo-visualization  display. 

65  Such  widgets  are  to  be  provided  to  allow  users  to  adjust  settings  on  the  general  features  of  the  layers  themselves  (e.g., 
transparency,  scaling,  and  so  forth). 

66  This  feature  allows  users  to  readily  invoke  and  dispense  with  individual  layers  or  entire  layer  sets  with  a  single  select-and- 
click  tactic. 
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Figure  1.6-4:  Auxiliary  Information  Displays 


(Not  to  Scale) 


These  subsidiary  components  are  as  follows: 

•  The  Time  Display  (topmost)  gives  the  standard  date  and  time  to  remind  the  user  of  this  critical 
parameter. 

•  The  Selection  Indicator  (middle)  provides  a  cue  for  what  kind  of  item  is  currently  highlighted  / 
selected  on  the  central  geo-visualization  display. 

•  The  Selection  Info  Window  (bottom)  is  a  space  within  which  summary  data  on  the  selection  is 
provided. 

The  Selection  Indicator  and  Selection  Info  Window  parts  of  Figure  1.6-4  provide  an  illustrative  case  of 
how  these  elements  are  intended  to  aid  the  user.  In  this  illustrative  case,  a  mission  route  is  selected  on 
the  central  display.  The  Selection  Indicator  cues  the  user  that  a  'Route'  is  the  current  selection.  The 
Selection  Info  Window  provides  summary  data  on  the  mission  /  flight  associated  with  the  selected  route. 
The  summary  data  provided  in  the  Selection  Info  Window  will,  of  course,  vary  with  the  class  and 
identity  of  the  item(s)  selected  on  the  graphical  display.67 


67  One  might  well  bring  up  the  question  of  whether  or  not  the  functions  of  the  Auxiliary  Information  Displays  (particularly 
the  Selection  Indicator  and  the  Selection  Info  Window)  could  just  as  well  be  accomplished  through  interactive  pop-ups  on  the 
central  geo-visualization  display  itself.  This  is  a  reasonable  point  to  ponder.  However,  reliance  on  pop-ups  alone  in  the 
context  of  a  potentially  very  complex  visual  display  could  prove  frustrating  to  users.  The  elements  of  this  Auxiliary 
Information  Display  area  provide  a  persistence  which  is  necessary  should  the  user  need  to  select  something  on  the  central 
display,  then  move  his  /  her  attention  elsewhere  (e.g.,  layer  controls  or  an  outboard  palette).  This  persistence  affords  the  user 
a  capability  for  being  reminded  of 'what  I  last  selected'  that  cannot  easily  or  cleanly  be  afforded  using  dynamic  pop-ups 
alone. 
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‘Outboard  ’  Window  Selector 


As  a  general-purpose  visualization  aid,  the  FVT  is  capable  of  being  used  for  a  variety  of  functions  and 
by  a  variety  of  roles  within  the  TACC  team.  As  discussed  earlier,  it  is  intended  to  be  able  to  be 
employed  as  both  a  management  oversight  display,  a  group  situation  awareness  display,  and  an 
individual  planning  aid.  This  generality  comes  at  the  expense  of  a  trade-off.  Because  it  is  general  in 
scope  and  function,  the  FVT  cannot  simultaneously  serve  as  a  specialized  tool  for  each  and  every  role 
for  whom  it  is  intended.  Even  though  the  FVT  is  designed  to  serve  as  a  summary  visualization  display, 
it  cannot  supplant  all  the  other  tools  in  the  current  and  prospective  TACC  IT  inventories.  There  will 
always  be  a  potential  need  to  invoke  another  tool  to  (e.g.)  edit  crew  papers.  Similarly,  there  will  always 
be  a  potential  need  to  invoke  (e.g.)  CAMPS  or  GDSS-2  to  check  on  details  associated  with  a  given 
mission. 

As  a  result,  the  FVT  concept  is  designed  to  be  a  central  component  of  a  flexible  suite  of  tools  supporting 
the  TACC  team.  It  provides  the  main  'window  on  the  missions  in  the  world',  and  will  presumably  be  a 
regular  (if  not  persistent)  presence  on  a  variety  of  desktops  and  other  displays.  Other  tools  and  aids  will 
need  to  be  flexibly  invoked  from  the  FVT  as  requirements  dictate.  To  provide  for  such  invocation  of 
'outboard'  aids,  the  FVT  incorporates  an  Outboard  Window  Selector  component  in  its  lower  right-hand 
comer.  The  Outboard  Window  Selector  concept  is  illustrated  in  Figure  1.6-5. 
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Figure  1.6-5:  'Outboard'  Window  Selector 
(Not  to  Scale) 
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As  Figure  1.6-5  shows,  the  Outboard  Window  Selector  provides  a  reference  list  of  additional  windows  / 

•  Z  Q 

displays  /  palettes  the  user  can  invoke  as  needed.  Some  of  these  are  for  reference  purposes,  while 
others  are  ‘working  spaces’  for  entering  /  creating  /  modifying  mission-related  data.  The  vertically- 
order  set  of  rectangular  buttons  are  used  to  invoke  these  outboard  windows  /  palettes. 

These  buttons  are  color-coded  to  indicate  (context-sensitive)  relevance  to  the  user’s  position  and/or 
current  state  of  his  /  her  selection  (cf.  the  discussion  of  the  Selection  Indicator  above).  For  the  sake  of 
illustration,  Figure  1.6-5  uses  'blue'  to  connote  a  'relevant'  asset  and  'gray'  to  connote  an  asset  of  no  or 
very  limited  relevance.69  Let  us  illustrate  this  concept  by  reference  to  the  illustrative  state  of  the 
Selection  Indicator  discussed  above.  In  this  case,  the  ‘route-centric’  selection  de-emphasizes  the  ORM 
and  NOT  AMS,  because  neither  of  these  categories  of  data  pertains  to  ‘routes’  per  se.70 

Color-coded  indicators  (the  small  circular  elements  to  the  right)  cue  the  user  as  to  which  available 
outboard  options  have  been  invoked.  In  Figure  1.6-5,  only  the  Route  Editor  (discussed  later)  has  been 
invoked.  This  feature  is  included  to  aid  the  user  in  managing  a  potentially  large  number  of  outboard 
aids  within  a  finite  display  area.71  If  one  were  to  include  multiple  color-coding  for  these  indicators,  the 
FVT  could  provide  the  user  with  alert  status  cueing  with  respect  to  the  outboard  palettes  as  well.  For 
example,  a  'colored'  indicator  would  cue  the  user  that  the  associated  outboard  asset  was  'open  /  active'. 
If  the  indicator  color  was  green,  the  user  would  know  from  the  FVT  alone  that  no  outstanding  alert 
conditions  were  flagged  on  that  outboard  asset.  Conversely,  if  the  indicator  color  was  red,  the  user 
would  be  cued  that  an  outstanding  alert  condition  had  been  flagged,  and  (e.g.)  he  /  she  could  simply  hit 
the  associated  button  to  bring  that  particular  outboard  asset  to  the  foreground. 


Work-Centered  Rationale  for  the  FVT  +  Outboard  Assets  Architecture 

The  reorganization  of  our  WCSS  designs  during  Phase  II  was  deliberately  aimed  at  modularizing  work 
support  features  to  provide  a  suite  or  toolkit  capable  of  supporting  the  breadth  and  diversity  of  TACC 
team  members'  activities.  Recall  that  the  earlier  discussion  on  collaboration  concluded  that  TACC  didn't 
need  a  means  for  realtime  joint  work  activity  so  much  as  a  means  for  keeping  all  team  members 
'coordinated'  with  respect  to  the  subject  matter  (missions,  routes,  etc.).  This  theme  was  an  important 
factor  in  deciding  to  pursue  modularity  and  flexible  interoperation  rather  than  a  range  of  single  'all-in- 
one'  WCSS  concepts,  all  somewhat  redundant  and  each  tailored  to  a  specific  position  or  role.  The 
toolkit  architecture  presented  here  is  judged  to  be  the  optimal  approach  for  supporting  the  entire  TACC 
team  in  the  most  comprehensive  and  coherent  fashion.  From  the  perspective  of  functionality  and  work- 
centered  support,  the  reasons  for  this  claim  include: 


68  The  particular  set  of  items  illustrated  in  Figure  1.6-5  represents  only  a  notional  list  generated  for  the  sake  of  illustration.  A 
definitive  list  was  not  developed  during  GAM  AT  Phase  II. 

69  The  color-coding  to  cue  the  user  on  contextual  relevance  is  not  meant  to  limit  the  user's  options  for  invoking  outboard 
assets.  All  the  buttons  are  intended  to  be  'functional'  at  all  times.  This  color-coding  is  only  an  overlay  or  gloss  for  the 
purposes  of  guiding  user  attention  and  minimizing  the  cognitive  burden  of  trying  to  figure  out  which  outboard  assets  are  most 
relevant  to  drilling  down  on  the  item  (e.g.,  a  route)  he  /  she  has  designated  as  the  current  selection. 

70  To  further  illustrate,  had  the  user's  selection  been  (e.g.)  a  'weather  element',  the  WX-related  ORM  would  have  been 
highlighted  as  'relevant'.  Similarly,  had  the  selection  been  an  individual  'airfield'  the  NOTAMS  button  would  have  been 
highlighted  as  'relevant'. 

71  As  demonstrated  in  the  IFM  project  (2000  -  2001),  the  issue  of  display  overload  within  finite  screen  space  was,  and  still  is, 
an  important  human  factors  problem  in  TACC  operations. 
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•  This  minimizes  the  number  of  redundant  features  otherwise  replicated  across  a  set  of  role-specific 
‘all-in-one’  WCSS  units. 

•  This  minimizes  the  scope  and  complexity  of  updates  and  re-designs  (through  modularity). 

•  This  maximizes  ‘common  look  and  feel’  and  fosters  a  better  basis  for  TACC  team  collaboration. 

•  The  core  visualization  (FVT)  provides  a  basis  for  management  viewing  things  just  as  ops  staff  do. 

•  Starting  from  the  common  work  domain  visualization  afforded  by  the  FVT,  the  user(s)  can  freely 
and  flexibly  invoke  additional  visualizations  and  /  or  tools. 

•  This  maximizes  the  ability  of  each  TACC  user  to  mix  ‘n’  match  visualizations  and  tools  to  fit  his  / 
her  current  issue(s)  and  situation(s)... 


More  generally,  this  approach  has  benefits  with  respect  to  TACC  operational  administration,  oversight 

of  its  technological  infrastructure,  and  the  ability  to  evolve  that  infrastructure  as  time  goes  on.  These 

more  enterprise-wide  benefits  will  result  from  the  following  factors: 

•  Keeping  the  core  /  common  visualization  component  separate  allows  for  independent  refinement  of 
the  ‘outboard’  tools.72 

•  This  maximizes  the  opportunities  for  fine-tuning  these  tools  to  suit  current  requirements. 

•  This  maximizes  the  tractability  of  modifying  /  refining  these  tools  over  time. 

•  Allowing  common  (read)  access  to  each  other’s  tools  permits  TACC  team  members  (including 
management)  to  view  status  and  issues  in  a  coherent  and  mutually-understandable  way.73 

•  This  approach  pushes  the  notion  of  the  1990's-era  concept  of  ‘common  operating  picture’  to  achieve 
its  originally  intended  payoff  -  ‘commonly-pictured  operations’  (i.e.,  coordinated  situation  awareness, 
decisions,  and  actions).74 


72  In  other  words,  modularity  is  the  recommended  strategy  for  mitigating  the  historical  vulnerability  of  TACC  operations  to 
delayed  improvement  by  having  to  wait  on  global  revisions  to  large  all-in-one  information  systems. 

73  This  is  a  deliberate  strategy  to  promote  better  'coordination'  (cf.  discussion  of  collaboration  in  TACC)  both  'horizontally' 
across  roles  /  positions  and  'vertically'  through  the  administrative  strata. 

74  Indeed,  this  theme  of  'commonly  pictured  operations’  can  be  seen  as  the  top-level  outcome  of  a  work-centered  approach 
prioritizing  the  work  itself  as  the  subject  matter  (as  contrasted  with  the  mechanics  of  operating  one  or  another  specific 
information  system). 
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The  Route  Editor 


Now  let  us  move  on  to  consider  a  specific  tool  intended  to  serve  as  one  of  the  outboard  aids  invocable 
from  the  FVT.  During  the  last  months  of  GAMAT  Phase  II  the  single  such  outboard  tool  most  closely 
linked  to  our  focal  flight  planning  task  was  initially  designed  and  briefed.  This  tool  was  labeled  the 
Route  Editor,  because  it  was  designed  to  offer  flight  planners  (and  other  personnel  conducting  notional 
flight  planning)  capabilities  to: 

•  Generate  or  invoke  an  ACFP  route  specification  associated  with  the  given  sortie 

•  Edit  the  text  specification  for  that  route 

•  Display  the  ramifications  of  a  new  or  modified  route  specification  in  a  graphical  display  (on  the 
FVT) 

•  Store  'snapshots'  (local  copies)  of  a  route  specification  for  subsequent  review  and  evaluation 

•  Cue  the  user  on  the  progress  and  status  of  his  /  her  (re-)planning  work  using  the  sort  of  'checklisting' 
structure  initially  introduced  for  the  flight  managers  in  the  IFM  project 

•  Manage  interactions  and  synchronization  between  the  state  of  this  outboard  tool  and  an  associated 
FVT. 


The  Route  Editor  was  deliberately  designed  to  meet  the  objectives  outlined  earlier  in  this  report  with 
regard  to  the  flight  managers'  Sortie  Manager  (which  derived  from  an  IFM  project  WCSS  concept).  The 
Route  Editor  represents  a  more  generic  version  of  the  Sortie  Manager  from  which  any  FM-specific 
options  and  features  have  been  either  generalized  or  eliminated.  The  basic  form  of  the  Route  Editor  is 
therefore  very  similar  to  the  Sortie  Manager.  This  basic  layout  of  the  Route  Editor  is  illustrated  in 
Figure  1.6-6. 
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Figure  1.6-6:  The  Route  Editor  Concept 


(Not  to  Scale) 


The  Route  Editor  palette  is  subdivided  into  three  subareas  -  a  Header,  a  Working  Area,  and  a  Plan  /  Edit 
Controls  area.  The  Working  Area  is  a  general  purpose  window  for  the  presentation  and  interactive 
editing  of  text  (e.g.,  route  specifications).  It  is  into  this  Working  Area  that  route  data  associated  with  a 
given  sortie  will  be  pulled  for  review,  evaluation,  and  manipulated.  The  other  two  subareas  require 
additional  description  and  discussion  in  the  following  subsections. 
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Header  Subarea 


The  Header  subarea  is  positioned  along  the  top  periphery  of  the  Route  Editor  palette.  This  header 
contains  both  display  elements  and  interactive  elements.  The  display  elements  provide  the  user  with 
basic  data  on  the  particular  mission  /  sortie  being  addressed  in  the  Route  Editor.  The  interactive 
elements  allow  the  user  to  (a)  flag  the  current  route  editing  work  as  'notional'  /  'actual'  and  (b)  to  couple 
the  state  of  the  Route  Editor  to  an  associated  FVT  display.  The  basis  for  grouping  these  particular 
elements  in  the  Header  subarea  is  that  these  things  pertain  to  the  status  and  the  subject  matter  of  the 
current  Route  Editor  itself,  and  not  to  the  content  being  reviewed  and  /  or  manipulated  within  the  Editor. 
The  elements  of  the  Route  Editor's  Header  are  illustrated  in  Figure  1.6-7. 
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Figure  1.6-7:  The  Route  Editor  Header  Elements 
(Not  to  Scale) 


A  summary  description  of  the  Route  Editor  Header  elements  includes  the  following  overview 

comments: 

•  Basic  menus  (upper  left)  allow  for  local  control  of  Route  Editor  palette  within  the  presumptive 
Windows  operating  environment. 75 

•  Checkboxes  for  ‘Notional’  versus  ‘Actual’  allow  specification  of  (and  cueing  for)  the  relative  status  of 
the  route  product  being  addressed  in  this  Route  Editor.  This  feature  permits  the  user  to  use  the  Route 
Editor  as  a  sketchpad  for  (e.g.)  notional  flight  (re-)planning  without  running  the  risk  of  publishing  a 
local  or  transient  work  product  as  if  it  were  final  and  actionable. 

•  Basic  information  text  windows  (along  top)  provide  on-palette  cueing  for  the  most  important  ‘factoids’ 
relating  to  the  mission  for  which  the  given  route  is  being  displayed:76 

•  Mission  number 


75  The  inclusion  of  such  menus  in  the  WCSS  concept  sketches  is  a  concession  to  the  Windows  environment  in  which  the 
GAMAT  prototyping  work  has  been  conducted.  These  menus  are  therefore  not  strictly  components  of  the  WCSS  design 
concept  itself.  Because  they  are  peripheral  'stubs',  they  will  not  be  discussed  further  in  this  report. 

76  The  set  of  informative  factoids  chosen  for  inclusion  in  the  Route  Editor  header  is  based  on  the  set  of  referents  most 
commonly  cited  as  key  descriptors  for  a  given  mission  during  our  last  5  years'  work  with  AMC/TACC. 
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•  Departure  port  (ICAO) 

•  Arrival  port  (ICAO) 

•  Launch  time 

•  Mission  type 

•  Aircraft  type 

•  Manually-selectable  ‘Coupled  /  De-Coupled’  radio  buttons  permit  user  to  disengage  Route  Editor  from 
interactive  linkage  with  FVT  (if  need  be).77 


The  inclusion  of  both  (a)  notional  /  actual  flagging  and  (b)  FVT  coupling  status  may  seem  somewhat 
redundant  at  first  glance,  but  it  isn't.  Flagging  a  route  specification  as  either  'notional'  or  'actual'  (i.e., 
'official'  or  'actionable')  is  a  matter  of  designating  the  work  product  content  in  the  context  of  its  potential 
usage.  Designating  coupled  status  with  regard  to  a  separate  FVT,  on  the  other  hand,  is  a  matter  of 
designating  whether  or  not  the  current  state  of  Route  Editor  content  (perhaps  not  yet  ready  to  become  a 
final  'product')  is  to  be  graphically  visualized  in  the  course  of  generating  such  a  work  product.  As  such, 
these  are  two  distinct  things,  and  the  controls  pertaining  to  them  must  be  similarly  distinguished.78 


Plan  /Edit  Controls  Subarea 

The  Sortie  Manager  which  provided  the  conceptual  precedent  for  the  Route  Editor  was  specifically 
configured  to  reflect  and  to  cue  the  flight  manager  on  the  canonical  stepwise  course  of  his  /  her  flight 
planning  process.  A  series  of  color-coded  indicators,  checkboxes,  and  text  display  elements  were 
combined  to  provide  a  running  summary  of  what  steps  had  been  completed,  which  steps  were  pending, 
and  some  quick  cueing  on  data  critical  to  certain  of  the  steps.  This  work-centered  design  theme  was 
carried  forward  into  the  Route  Editor  WCSS  concept. 


77  This  feature  allows  the  user  to  'couple'  an  FVT  to  the  Route  Editor  such  that  modifications  made  textually  to  a  route 
specification  can  be  graphically  visualized.  As  will  be  seen  shortly  (in  the  discussion  on  the  Plan  /  Edit  Controls  subarea)  this 
may  be  the  FVT  from  which  the  Route  Editor  was  initially  invoked  or  a  new  one  generated  solely  as  an  adjunct  to  the  Editor 
palette. 

78  For  example,  a  'quick  fix'  or  straightforward  addition  of  text  to  a  route  specification  might  not  need  to  motivate  the  time 
and  processing  required  to  generate  an  associated  FVT  visualization.  This  might  apply  regardless  of  whether  the  route 
specification  at  issue  is  'notional'  or  'actual'.  As  such,  FVT  visualization  may  be  'optional',  whereas  designation  of  plan  status 
is  something  that  must  always  be  done. 
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However,  this  does  not  mean  that  the  Route  Editor’s  procedural  cueing  and  informative  elements  are  the 
same  as  (or  even  very  similar  to)  those  portrayed  on  the  Sortie  Manager  palette.  There  are  some 
important  differences  between  the  two  WCSS  concepts.  The  Sortie  Manager  evolved  from  a  concept 
specifically  designed  for  flight  managers.  At  the  time  of  the  WCSS  effort  generating  this  concept  (2000 
-  2001),  flight  managers  had  no  capability  for  graphically  visualizing  route  specifications.  They  worked 
with  ACFP  flight  plans  provided  in  draft  form  by  the  flight  planning  shop  or  generated  by  the  flight 
managers  themselves.  At  the  time  of  the  IFM  project  our  WCSS  analysis  was  focused  on  the  relatively 
simplistic  FM  function  of  generating  and  issuing  crew  papers  for  each  of  a  relatively  few  missions  or 
sorties  previewed  specifically  pre-selected  for  FM  processing.  As  such,  the  FM  work  process  studied 
and  analyzed  4  years  ago  did  not  incorporate  the  full  range  of  complexities  which  confront  mission 
planners,  DIP  planners,  flight  planners,  and  even  the  proliferating  population  of  flight  managers. 

In  other  words,  the  original  WCSS  concept  seminal  to  the  Sortie  Manager  was  designed  to  support  a 
fairly  unilinear  documentation  process  within  which  graphic  visualization  was  no  more  than  a  pipe 
dream  and  few  if  any  routing  alternatives  or  options  were  ever  generated  for  consideration.  The  scope 
of  design  has  now  grown  to  encompass  the  TACC  team  generally,  and  graphical  support  is  now  a  reality 
(at  least  in  prototype  form).  The  arrival  of  feasible  route  visualization  capabilities  means  that  a  route 
planning  tool  needs  to  be  capable  of  interacting  with  its  visualization  component(s).  Our  GAMAT 
Phase  II  prescription  for  modularization  of  WCSS  tools  means  that  this  capability  has  to  be  tailored  to 
account  for  interactions  with  separate  but  referentially  and  functionally  interlinked  on-screen  tools.  To 
account  for  the  decision  processes  of  all  relevant  TACC  team  members,  our  new  route  planning  WCSS 
needs  to  be  able  to  handle  multiple  (and  potentially  numerous)  alternative  or  optional  candidate  work 
products.  Finally,  with  our  scope  of  design  and  implementation  expanded  to  address  intra-team  (hence 
inter-role;  inter-unit)  collaboration,  the  new  WCSS  concept  has  to  provide  for  sharing  and  forwarding 
both  intermediate  and  final  route  planning  products. 

The  Route  Editor's  analogue  to  the  Sortie  Manager's  'checklist'  display  and  control  area  is  the  Plan  /  Edit 
Controls  subarea  illustrated  in  Figure  1.6-8. 
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Figure  1.6-8:  The  Route  Editor  Plan  /  Edit  Controls  Subarea 

(Not  to  Scale) 


The  main  descriptive  points  to  be  made  about  this  design  component  and  its  intended  functionalities  are 

as  follows: 

•  As  was  done  in  the  Sortie  Manager,  the  elements'  vertical  organization  reflects  overall  task  /  process 
flow,  with  earlier  /  precedent  steps  being  portrayed  'uppermost'  and  later  /  subsequent  steps  being 
portrayed  'lowermost'. 

•  Circular  indicators  associated  with  each  major  process  step  /  option  cue  the  user  on  current  status  for 
that  step  /  task  (Green  =  Done;  Yellow  =  In  Process;  Gray  =  Not  Yet  Done;  Red  =  Alert  /  Prompt  for 
Required  Action). 

•  Initial  route  specifications  can  be  entered  in  3  ways: 
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•  Query  ACFP  (yielding  a  set  of  candidate  routes) 

•  Import  ('pull')  it  from  a  current  FVT  selection  (i.e.,  show  text  of  route  highlighted  on  map 
visualization) 

•  Edit  it  from  scratch  (including  pasting  in  text)79 

•  Editing  is  done  in  Work  Area  using  conventional  text  processing  tactics. 

•  Generating  a  graphical  representation  of  the  current  route  specification  is  done  by  ‘pushing’  it  to  the 
extant  (or  a  new)  FVT.80 

•  Importing  a  FVT  -  modified  route  spec  is  done  by  ‘pulling  a  snapshot’  back  into  the  Route  Editor.81 

•  A  ’Save’  button  permits  proactive  storage  of  a  draft  route  spec  (with  user-defined  labeling  as  option). 

•  Each  ‘push’  and  ‘pull’  action  automatically  triggers  a  similar  storage  action  (without  having  to  hit 
‘Save’). 

•  These  tactics  allow  the  user  to  generate  and  accrete  a  set  or  list  of  candidate  route  specifications  for 
review,  further  editing,  and  /  or  export  as  a  final  planning  product. 

•  The  accreted  list  of  draft  route  specs  is  organized  in  accordance  with  chronological  origin  (allowing 
trace  of  planning  process). 

•  First  on  the  list  is  ‘Original’  (first-pushed),  and  last  will  be  the  latest  ‘Save’. 82 

•  Intermediate  draft  products  are  listed  as  ‘Push’  and  ‘Snap’(-shot)  items. 


79  Though  this  scratch  option  may  seem  archaic  and  something  to  be  eliminated,  our  KA  during  GAMAT  Phase  II  repeatedly 
indicated  that  proficient  flight  planners  sometimes  do  just  this  -  particularly  when  dealing  with  novel  routing  conditions  or 
when  having  to  operate  under  time  pressure. 

80  The  reason  provision  was  made  for  designating  current  versus  new  FVT  displays  is  to  afford  users  a  number  of 
opportunities  which  may  be  needed,  depending  on  role  and  circumstances.  For  example,  the  flexibility  to  generate  multiple 
'slave'  FVT's  would  give  a  flight  planner  the  ability  to  visualize  and  compare  a  set  of  candidate  routes.  To  give  another 
example,  if  the  extant  FVT  is  in  collective  use  (e.g.,  as  a  team  display),  it  would  be  unwise  to  have  one  team  member 
'posting'  intermediate  or  tentative  routes  on  such  a  general  situation  awareness  display. 

81  Although  this  'pulling  a  snapshot'  capability  is  functionally  identical  to  an  initial  'import'  action,  there  is  an  important 
distinction  to  be  drawn  between  the  two  acts.  The  'import'  is  an  optional  tactic  for  bootstrapping  work  done  with  the  Route 
Editor.  A  'snapshot  puli'  is  a  mandatory  tactic  for  capturing  the  state  of  an  FVT  visualization  as  an  intermediate  work 
product.  The  necessity  for  drawing  this  distinction  is  reinforced  by  the  fact  that  we  must  allow  for  more  than  one  FVT  to  be 
involved  in  a  particular  route  editing  /  planning  task. 

82  This  ordering  is  specified  deliberately  to  allow  the  user  to  index  the  candidate  route  specifications  in  accordance  with  the 
chronological  order  in  which  he  /  she  addressed  and  /  or  processed  them.  This  correlates  intermediate  work  product  indexing 
with  in-task  experience  and  minimizes  the  cognitive  burden  that  would  result  if  the  user  were  required  to  index  the 
potentially  sizeable  candidate  specifications  list  using  arbitrary  labels. 
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•  Although  items  accrete  to  this  candidate  list  only  via  Push  /  Pull  /  Save  /  Publish  actions,  they  can  be 
deleted  directly.83 

•  When  ‘done’,  user  can  forward  current  route  spec  to  other  TACC  team  members  via  ‘Send  To’. 

•  As  appropriate,  user  can  use  ‘Publish’  to  accrete  the  route  spec  to  TACC  team  IT  assets  (e.g., 
Electronic  Mission  Folder). 


These  last  two  features  ('Send  To'  and  'Publish')  allow  the  Route  Editor's  users  to  participate  in  the  larger 
collaborative  context  of  the  TACC  team.  Using  the  'Send  To'  option,  a  user  can  forward  a  candidate 
specification  for  review  /  evaluation  /  approval  by  another  team  member.  To  given  one  pertinent 
example,  this  could  be  the  primary  mechanism  by  which  a  mission  planner  forwards  a  notional  route  / 
flight  specification  to  the  DIP  shop  for  initial  review.  Using  a  separate  'Publish'  capability  allows  the 
user  a  discrete  means  for  exporting  his  /  her  final  route  planning  product  to  the  TACC  team  data 
infrastructure  assets.  Differentiating  between  'Send  To'  and  'Publish'  accounts  for  the  possibility  that  the 
user  may  have  to  circulate  a  draft  route  plan  one  or  more  times  before  committing  to  a  final  version. 


An  Illustrative  Use  Scenario  for  the  FVT  /  Route  Editor  Combination 

To  illustrate  how  the  FVT  and  the  Route  Editor  are  intended  to  be  used,  let  us  return  to  our  earlier 
recommendation  that  a  mission  planner  be  enabled  to  generate  his  /  her  own  notional  flight  plans. 
Figure  1 .6-9  illustrates  the  basic  process  path  for  accomplishing  this  using  the  combination  of  the  FVT 
and  a  Route  Editor. 


s  >  This  feature  allows  the  user  to  proactively  and  easily  eliminate  candidate  specifications  as  he  /  she  determines  they  are  of 
no  further  importance  to  his  /  her  task. 
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First,  the  mission  planner  identifies  and  selects  a  pending  mission  from  the  Mission  Status  Display  (his 
'to-do  list').  Invoking  an  FVT  in  the  context  of  this  particular  mission  record  gives  him  /  her  a  geo- 
referenced  visualization  display  for  the  region  to  be  traversed.  By  invoking  a  Route  Editor  from  the 
FVT,  the  mission  planner  is  presented  with  a  working  palette  into  which  he  /  she  can  (e.g.)  import  an 
ACFP  flight  plan,  edit  it,  and  save  it  as  a  notional  work  product.  Using  the  interlinking  between  the 
FVT  and  the  Route  Editor,  he  /  she  can  both  display  the  text  specifications  derivative  of  the  FVT's 
graphically-displayed  (and  /  or  manipulated)  route  and  conversely  display  the  graphical  representation 
for  textual  route  specifications  being  edited  in  the  Route  Editor.  Once  he  /  she  is  satisfied  with  the 
specification,  it  can  be  saved  or  published  to  (e.g.)  the  Logbook  or  the  Electronic  Mission  Folder.84 


8 4  In  addition,  he  /  she  can  forward  the  candidate  specification  to  the  DIP  shop  using  the  'Send  To'  feature  so  as  to  get  an 
initial  review  of  the  prospects  for  diplomatic  clearances. 
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1.7  Work-Centered  Analysis  and  Design  Recommendations  for  TACC  Flight 
Planning  and  Flight  Planning-related  Collaboration  Summary 

The  GAMAT  Phase  II  flight  planning-related  analysis  and  design  work  covered  a  diverse  set  of  topics 
and  much  conceptual  ground.  The  two  primary  foci  for  this  portion  of  the  Phase  II  work  were  (a) 
opportunities  for  flight  planning  related  collaboration  in  the  TACC  (although  much  is  generalizable 
beyond  a  strict  relationship  to  flight  planning)  and  (b)  providing  WCSS  design  concepts  aimed  at 
supporting  the  flight  planning  function.  These  two  foci  were  intertwined  and  had  to  be  addressed  with 
respect  to  each  other.  For  one  thing,  the  flight  planning  function  is  arguably  the  most  centrally-critical 
one  in  the  overall  TACC  planning  and  execution  process  path.  As  such,  changes  to  the  flight  planning 
phase  of  the  process  path  have  major  implications  for  the  TACC  team  (and  their  collaborative  prospects) 
in  general.  Conversely,  some  of  our  perceived  leverage  points  for  improving  overall  TACC  team 
performance  (e.g.,  earlier  generation  of  notional  flight  plans)  required  innovations  which  would  extend 
flight  planning  functions  to  other  positions  and  units. 

As  discussed  in  Chapter  1.3,  the  GAMAT  Phase  II  work  produced  the  following  analytical  results  with 
respect  to  TACC  team  collaboration: 

•  Identification  of  temporality  as  the  primary  context  for  addressing  constraints  on  sorties 

•  Identification  of  the  need  to  eliminate  'blind  spots’  that  prevent  individual  roles  and  positions  from 
maintaining  situation  awareness  on  the  overall  TACC  workstream  and  the  mission  'cases'  comprising 
that  workstream 

•  Specific  interventions  (e.g.,  mission  planners  generating  their  own  notional  flight  plans)  which  could 
improve  overall  TACC  team  performance 

•  A  review  and  analysis  of  the  extent  to  which  our  precedent  WCSS  concepts  from  HISA,  IFM,  and 
GAMAT  Phase  I  could  be  extensible  to  support  the  entire  TACC  collaborative  team  rather  than  the 
particular  roles  for  which  they  were  originally  targeted. 

•  An  assessment  of  what  specific  features  could  be  preserved  (and  which  needed  to  be  extended  or 
generalized)  to  achieve  this  collaborative  objective. 

•  An  assessment  of  the  extent  to  which  our  novel  and  evolving  WCD  approaches  and  methods  have 
permitted  us  to  design  for  collaboration  from  the  very  beginning. 


As  discussed  in  Chapter  1.4,  the  GAMAT  Phase  II  work  produced  the  following  results  with  respect  to 
the  flight  planning  function  in  particular: 

•  Identification  of  the  main  flight  planning  performance  problems  capable  of  being  addressed  and 
ameliorated  using  WCSS  innovations. 

•  Specification  of  the  particular  WCSS  interventions  necessary  to  ameliorate  these  problems, 
including: 
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■  Incorporation  of  realtime  graphical  visualization  in  the  IT  support  aids  providing  the  flight 
planning  staff. 

■  Incorporation  of  new  route  manipulation  capabilities  leveraging  this  new  graphical 
representation  (e.g.,  via  direct  manipulation  of  on-screen  elements). 

■  Renovation  of  the  current  and  /  or  next-generation  F2  Database  (or  equivalent)  to  permit 
addressing  routes  at  a  minimu'm  of  two  levels  of  granularity. 

■  Leveraging  the  implied  imposition  of  a  more  structured  organizational  schema  for  route  data  to 
make  maintenance  of  the  flight  planners’  route  specification  database  both  more  efficient  and 
more  effective. 

■  Designing  flight  planning  IT  aids  such  that  they  were  of  utility  to  the  broader  population  of 
TACC  users  (i.e.,  not  designing  solely  for  the  experienced  flight  planners). 

■  Making  provision  for  supporting  other  TACC  players  (most  particularly  the  mission  planners) 
with  a  capability  for  generating  notional  flight  plans  without  having  to  request  the  flight  planners 
do  it  for  them. 

■  Illustrating  the  utility  of  facilitating  TACC  team  situation  awareness  on  constraint  and  alert 
conditions  affecting  mission  /  flight  viability,  but  that  are  not  directly  and  immediately 
inspectable  with  current  individual  tools. 


As  presented  in  Chapters  1.5  and  1.6,  we  generated  new  or  next-generation  WCSS  design  concepts 
intended  to: 

•  make  route  rationale  and  constraints  more  visible; 

•  facilitate  all  TACC  team  members'  abilities  to  understand,  evaluate  and  revise  a  flight  plan; 

•  afford  mission  planners  more  information  on  options  and  alternatives; 

•  allow  more  timely  capture  and  presentation  of  information  necessary  for  better  situation  awareness 
(SA); 

•  eliminate  current  ‘blind  spots’  in  the  TACC  process  path; 

•  enable  more  proactive  response  across  the  organization; 

•  reduce  mission  delays  and  mission  ‘no-gos’  and; 

•  provide  aids  to  enable  Flight  Planners  to  more  efficiently  capture  and  maintain  the  corporate  flight 
planning  knowledge  base 

•  Provide  more  expedient  means  for  editing  work  products. 
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•  Afford  users  a  richer  way  to  search  /  index  the  database  of  ‘precedent  routes’. 

•  Eliminate  bottlenecks  and  delays  by  providing  direct  access  to  relevant  work  products  (e.g.,  notional 
flight  plans  for  DIP  shop.  Mission  Planners). 


The  specific  WCSS  innovations  prescribed  in  this  report  illustrate  the  intertwining  of  the  collaboration 
theme  and  the  flight  planning  focus  in  both  their  framing  and  their  suggested  payoffs  to  individual  users, 
their  units,  and  the  TACC  team  as  a  whole. 
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1.8  Work-Centered  Support  System  for  Global  Weather  Management  Spiral  2 

Capability  Design  and  Demonstration 


Background 

The  first  phase  of  the  GAMAT  program  produced  the  first  spiral  of  a  demonstration  capability  of  the 
Work-Centered  Support  System  for  Global  Weather  Management  (WCSS-GWM).  The  WCSS-GWM 
was  designed  to  mitigate  the  impact  of  changing  weather  conditions  on  near  term  planned  and  en  route 
Air  Mobility  Command  (AMC)  missions  by  command  and  control  personnel  residing  in  AMC’s  central 
command  and  control  facility,  the  Tanker  Airlift  Control  Center  (TACC).  Because  of  their  satisfaction 
with  the  support  provided  by  the  demonstration  capability,  many  of  the  target  users  -  the  TACC/WXM 
Weather  Forecasters  and  TACC/XOC  Flight  Managers  -  began  using  the  demonstration  capability  to 
support  a  portion  of  daily  operations  in  the  TACC.  As  a  result,  additional  analysis  and  capability  was 
requested  by  AMC  personnel  to  more  efficiently  support  those  operations.  This  provided  research 
opportunities  to  experiment  with  expanding  the  basic  WCSS-GWM  framework  to  support  larger  user 
sets,  and  gain  additional  insight  into  the  scalability  of  the  basic  WCSS-GWM  framework. 

The  WCSS-GWM  is  a  software  client  application  designed  to  mitigate  the  impact  of  changing  weather 
conditions  on  near  term  planned  and  on  route  Air  Mobility  Command  (AMC)  missions  by  command  and 
control  personnel  residing  in  the  TACC.  Figure  1.8-1  shows  the  basic  user  interface  configuration  of  the 
WCSS-GWM  Spiral  1.  The  WCSS-GWM  provides  AMC  personnel  with  a  consolidated  view  of 
weather  and  air  mission  information  along  with  and  integrated  into  the  context  of  the  work  being 
performed.  It  supports  rapid,  flexible  and  adaptive  work  through  a  mix  of  user  interface  form  design 
and  automation.  It  augments  user  cognitive  capability  by  proactively  monitoring  relevant  information, 
reporting  potential  exceptions  and  providing  rapid  and  flexible  ways  to  understand  the  potential 
problems  constraints  to  enable  rapid  analysis  and  alternative  course  of  action  generation  and  decision 
making,  while  remaining  organized  with  respect  to  multiple  work  threads  (in  this  case  airlift  or  tanker 
sortie  planning  and  execution  support). 

In  a  more  specific  sense,  the  WCSS-GWM  consists  of  two  context  coordinated  panels  -  the  mission 
detail  panel  and  the  mission  summary  panel,  each  providing  distinct  but  related  contextualized 
information  that  allows  a  user  to  remain  in  the  proper  context  while  examining  problems  from  different 
perspectives  -  i.e.,  relative  to  specific  categorizations  and  geo-spatial  details  and  relative  to  summarial 
and  related  mission  categorizations.  It  enables  rapid  fusion  of  flight  path,  weather  and  other  relevant 
information  as  user  selectable  layers  to  enable  rapid  potential  course  of  action  generation  to  support 
problem  resolution.  It  enables  user-definable  intelligent  agent-based  exception  reporting  and  alerting 
when  significant  changes  in  weather  phenomena  are  detected  which  may  impact  those  missions.  It  also 
includes  an  Agent  Management  Tool  (AMT)  that  allows  users  to  flexibly  define  “watch  areas”  for 
specific  weather  events.  It  also  provides  a  more  general  capability  to  define  ‘exclusion  zones’  and  alert 
the  user,  when  a  mission  track  intersects  an  exclusion  zone. 
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Figure  1.8-1:  WCSS-GWM  Spiral  1 


A  variety  of  innovations  were  made  to  the  first  spiral  version  of  the  WCSS-GWM  to  enable  more 
efficient  support  for  TACC  operations  and  teams  based  on  additional  information  learned  during  the 
GAMAT  Phase  II  effort.  Some  of  these  capabilities  were  demonstrated  in  spiral  2  of  the  WCSS-GWM. 

Work-Centered  Support  System  for  Global  Weather  Management  (WCSS-GWM)  Spiral  2 
Demonstration  Capability 

This  section  summarizes  the  WCSS-GWM  Spiral  2  demonstration  capabilities.  For  more  detailed 
information  about  the  WCSS-GWM  Spiral  2,  see  the  WCSS-GWM  Users  ’  Manual  and  the  WCSS-GWM 
Users  ’  Manual. 

The  primary  groupings  of  changes  that  distinguish  the  WCSS-GWM  Spiral  2  (Figure  1.8-2)  capability 
from  the  WCSS-GWM  Spiral  1  capability  were  the: 

•  Addition  of  new  data  sources  and  data  source  update  rate  changes 

•  Additional  information  fusion  capability  instantiated  as  ‘layers’ 

•  Additional  alerting  capabilities 

•  User  Interface  display  and  control  changes 

•  Software  architecture  changes 
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Figure  1.8-2:  WCSS-GWM  Spiral  2 


Data  Source  and  Update  Rate  Changes 

The  WCSS-GWM  is  designed  as  a  network-centric  client  application.  It  was  designed  as  an 
independent  client  application  that  utilizes  data  from  a  variety  of  sources  to  provide  comprehensive 
work  support  aiding.  The  work-centered  requirements  analysis  determined  that  in  order  to  most 
efficiently  support  the  target  work  activities,  multiple  data  sources  not  residing  in  any  single  system 
were  required  to  support  the  functionality  instantiated  in  the  user  interface.  Following  are  the  data 
sources  utilized  by  the  WCSS  Spiral  2:  (Changes  from  the  Spiral  1  version  are  noted.) 

•  15th  Operational  Weather  Squadron  forecasts  from  the  150WS  distribution  server  as  created  in  the 
Operational  Weather  Squadron  Production  System  II  (OPS  II).  This  feed  was  added  during  Spiral  2 
development. 

•  Tropical  Storm  tracks  and  forecasts  from  the  Fleet  Numerical  Oceanography  Center  (FNMOC)  as 
they  are  created.  This  feed  was  added  during  Spiral  2  development. 

•  Weather-related  Operational  Risk  Management  (ORM)  integration  provided  by  the  Global  Decision 
Support  System  (GDSS).  This  feed  was  added  during  Spiral  2  development. 

•  Flight  path  information  from  the  Global  Decision  Support  System  (GDSS)  Integrated  Flight 
Management  (IFM)  backup  database  via  a  RIDL  report  every  4  minutes.  Spiral  1  received  this  feed 
every  hour. 
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•  Aircraft  Communications  and  Reporting  System  (ACARS),  Pilot  Reports  (PIREPs),  Aircraft  Reports 
(AIREPs),  Meteorological  Terminal  Air  Reports  (METARs)  and  Terminal  Aerodrome  Forecasts 
(TAFs)  from  the  15  Operational  Weather  Squadron  (15  OWS)(located  at  Scott  Air  Force  Base) 
distribution  server  every  3  minutes.  Spiral  1  also  received  these  same  feeds. 

•  Cloud  images  from  the  National  Oceanographic  and  Aeronautic  Administration  (NOAA)  Aviation 
Weather  Center  (AWC)  every  30  minutes.  Spiral  1  also  received  the  same  feed. 

•  Significant  Meteorological  Events  (SIGMETs)  from  NOAA  AWC  every  30  minutes.  Spiral  1  also 
received  the  same  feed. 

•  Satellite  derived  winds  from  Cooperative  Institute  for  Meteorological  Satellite  Studies  (CIMSS)  at 
the  University  of  Wisconsin  every  3  hours.  Spiral  1  also  received  the  same  feed. 

•  Digital  Aeronautical  Flight  Information  File  (DAFIF)  received  from  the  National  Geo-spatial 
Agency  (NGA)  every  28  days.  Spiral  1  also  received  the  same  feed. 


Additional  Information  Fusion  Capability 

Additional  ‘layers’  were  added  to  enable  users  to  rapidly  fuse  relevant  information  to  enable  enhanced 
support  for  existing  work  and  new  work  requirements  due  to  organizational  and  duty  position  changes 
discussed  in  Chapter  1 .3.  The  additional  layers  are: 

•  Tropical  storm  track  path  history  and  projection  for  currently  active  storms 

•  15  Operational  Weather  Squadron  annotated  weather  forecast  charts  -  imported  from  the  OPS  II 
system 

•  Exclusion  zones 

•  Air  routes 

•  Navigational  aids 

•  Flight  path  waypoints 

•  Flight  Information  Regions 

•  Countries  -  indicates  country  name  when  mouse  hovers  over  country 

•  Cloud  ‘looping’  option  added  to  clouds  layer  images  to  show  recent  cloud  movement  history 
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Additional  Alerting  Capabilities 

•  Exclusion  zones  -  user  definable  regions  which  can  be  selected  as  alert  triggers  if  intersected  by  a 
flight  path 

•  SIGMETs  -  can  be  selected  to  provide  cautionary  (‘yellow’)  alerts  if  forecast  region  intersects  a 
flight  path 

•  Forecasts  -  can  be  selected  to  provide  cautionary  (‘yellow’)  alerts  if  forecast  region  intersects  a 
flight  path 


User  Interface  Display  and  Control  Changes 

The  changes  that  distinguish  the  WCSS-GWM  Spiral  2  capability  from  the  WCSS-GWM  Spiral  1  can 
be  grouped  by  changes  to  the  sortie  palette  capability  consist  of  changes  to  the  Sortie  Palette  and 
changes  to  the  Mission  Detail  panel 


Changes  to  the  Sortie  Palette 

•  Additional  mission-related  information  filtering  and  ordering  functions  -  Includes  the  ability  to 
reorder  the  sorties  list,  filter  the  sorties  to  be  displayed,  monitor  airfield  and  route  conditions  by 
sortie,  and  monitor  alerts  by  sortie. 

•  Addition  of  Operational  Risk  Management  (ORM)  information  for  each  mission.  ORM  values 
are  color-coded  (red,  yellow,  green,  gray)  and  mouse  hover  text  pop-up  provides  rationale  for 
ORM  values  assigned. 

•  Removal  of  ‘eyeball’  design  element  to  distinguish  flight  managed  missions  from  non-flight 
managed  missions.  The  capability  to  sort  by  flight  managed  and  other  sorting  alternatives  is 
provided  by  the  filtering  and  ordering  capability  discussed  above  and  negated  the  necessity  of  the 
‘eyeball’  cueing. 

•  Enhanced  alert  management  capability  to  enable  users  to  investigate,  acknowledge,  and  cancel 
alerts 

•  Addition  of  ‘alert’  menu  to  enable  management  of  existing  and  additional  alerting  capabilities 

•  Additional  summary  information  for  each  sortie,  including  mission  type  identifier,  flight 
manager  identifier  and  sortie  phase  status  information  relative  to  specific  elements  of  the 
planning  through  execution  continuum 
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Changes  to  the  Mission  Detail  Display 


•  The  ability  to  display  the  additional  layers  at  the  data  frequency  rates  indicted  in  the  ‘Data  source 
and  rate  update  changes’  and  ‘Additional  fusion  capability’  sections  above. 

•  Reconfiguration  and  relocation  of  the  satellite  derived  winds  and  ACARS  altitude  filtering 
selector  and  indicator 

•  Removal  of  the  mouse  mode  selection  as  ‘radio’  style  controls 

•  Redesign  and  consolidation  of  the  data  currency  cues 

•  Addition  of  ‘layer’  menus  to  facilitate  minimization  of  requirements  for  layer  display  scrolling 
necessary  due  to  the  increasing  number  of  layers  added  to  the  second  spiral 

•  Multi-user  Agent  Management  Tool  (AMT)  design  that  enables  users  to  either  retain  the  scribed 
agent  watch  area  within  a  single  client  or  allow  it  to  be  made  available  to  other  user  clients 

•  The  ability  to  display  automated  aircraft  position  reports  invoked  by  highlighting  the  flight  path 
of  the  desired  sorties 

•  The  ability  to  isolate  a  given  flight  path,  temporarily  hiding  all  others 

•  Three  screen  views  -  ‘standard’,  ‘compact’  and  ‘minimal’  that  display  varying  portions  of  the 
mission  detail  display  depending  on  use  and  user  preferences.  For  example,  the  minimal  display 
displays  no  controls.  It  is  intended  for  use  when  displaying  on  a  wall,  for  example,  where 
controls  are  unnecessary  and  better  use  available  display  space  to  display  more  of  the  geo-spatial 
view. 

•  The  ability  to  save  and  load  user  display  customizations  to  minimize  configuration  time  for  new 
user  sessions 

•  The  ability  to  save  the  map  display  as  a  .gif  or  .jpg  image 


Software  architecture  changes 

Changes  were  made  to  the  underlying  software  architecture  to  support  a  larger  number  of  users  and 
information  sharing  among  users  via  the  Agent  Management  Tool  functionality. 
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1.9  Glossary 


ACARS  -  Acronym  for  ‘Aircraft  Communications  and  Reporting  System’ 

ACFP  -  Acronym  for  'Advanced  Computer  Flight  Planner'.  The  label  for  a  software  application  used  by 
the  flight  planning  shop  to  generate  route  specifications  for  incorporation  into  a  mission's  planning 
record.  The  ACFP  system  automatically  generates  a  specification  for  fuel-optimized  routing  between 
two  airfields  (i.e.,  for  a  given  'city-pair'). 

ACT  -  Acronym  for  'Automated  Clearance  Tool'.  The  ACT  is  the  prototype  DIP  support  application 
developed  in  a  parallel  project  during  FY03  by  BBN  Technologies. 

AFWA  -  Air  Force  Weather  Agency 

AIREP  -  Acronym  for  ‘Air  Report’  from  an  aircraft. 

AMC  -  Air  Mobility  Command 

AR  -  Aerial  refueling. 

ATC  -  Air  traffic  control. 

Back  Office  -  The  main  work  area  allocated  to  the  15th  OWS  within  AMC  /  TACC.  This  is  a  separate 
office  space  within  which  the  majority  of  on-duty  WX  staff  work  during  their  shifts.  This  is  the  focal 
site  for  WX  staff  members'  generation  of  continuous  regional  forecasts,  shift  briefings,  weather  data 
monitoring,  and  handling  calls  from  active  missions  and  other  parties. 

Chartmaker  -  The  label  denoting  the  'graphics  guy'  -  i.e.,  the  junior  level  back  office  staffer  responsible 
for  monitoring  incoming  WX  data  and  generating  the  forecast  charts. 

City-Pair  -  The  dyad  of  departure  and  arrival  airfields  used  as  the  basis  for  generating  an  ACFP  route 
specification. 

DAFIF  -  Acronym  for  'Digital  Aeronautical  Flight  Information  File'.  The  set  of  flight-related 
information  used  as  the  realtime  reference  for  flight  conditions  and  constraints. 

DAP  -  Acronym  for  "Diplomatic  Automation  Program"  -  the  software  application  providing  the 
'Logbook'  used  by  all  TACC  staffers  to  accrete  documentation  relating  to  a  given  mission. 

DIP  -  Acronym  for  'diplomatic  clearance(s)'. 

DIP  Summary  Palette  -  A  WCSS  concept  generated  during  GAMAT  Phase  II  to  provide  rapid  situation 
awareness  on  the  existing  DIP  data  associated  with  a  given  sortie. 
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Diplomatic  Clearance  -  The  formal  credential  according  permission  from  a  foreign  nation  to  enter  and 
transit  its  airspace. 

Electronic  Mission  Folder  -  The  name  of  an  envisioned  IT  application  which  would  provide  all  units 
within  AMC  /  TACC  with  a  commonly-accessible  structured  record  for  each  mission  being  planned  and 
followed. 

EMF  -  Acronym  for  Electronic  Mission  Folder. 

ETA  -  Acronym  for  ‘Estimated  Time  of  Arrival’. 

ETD  -  Acronym  for  ‘Estimated  Time  of  Departure’. 

F2  Database  -  The  computerized  repository  for  storing  previously-delineated  ACFP  route  specifications 
for  future  reference  and  /  or  reuse.  The  F2  database  is  maintained  by  the  flight  planning  shop,  and  the 
level  of  effort  necessary  for  this  maintenance  has  grown  to  be  worthy  of  a  dedicated  position. 

F2  Route  -  A  label  for  a  previously  specified  or  'canned'  route  specification  stored  for  future  reference 
and  /  or  reuse  in  the  F2  database. 

Falcon  View  -  A  graphic  mapping  application  used  in  support  of  mission,  planning  and  execution. 
FalconView  is  a  GOTS  product  originally  developed  by  USAF  in  conjunction  with  partners. 

FCG  -  Acronym  for  Foreign  Clearance  Guide. 

FIR  -  Acronym  for  Flight  Information  Region.  A  FIR  is  essentially  a  geospatially-delineated  area 
(region)  correlated  with  a  governing  authority  (e.g.,  for  air  traffic  control).  FIR  boundaries  generally  do 
not  correlate  1-to-l  with  political  boundaries  or  other  area  delimiters. 

FIR  Boundary  -  The  boundary  circumscribing  a  given  Flight  Information  Region.  FIR  boundaries  are 
important  constructs  in  flight  planning  because  permissions  and  authority  (e.g.,  for  ATC)  begin  and  end 
at  FIR  boundaries. 

Flight  Planning  Palette  -  A  WCSS  concept  developed  during  the  IFM  project  (2000  -  2001)  and 
presented  to  TACC  staff  in  spring  2001.  This  palette  incorporated  representations  for  stepwise  FM 
planning  procedure  (to  provide  a  'checklist'),  a  text  subwindow  serving  as  a  general  work  area,  and 
miscellaneous  data  and  alert  features.  The  Flight  Planning  Palette  was  conceived  as  a  modular 
'clipboard'  to  be  employed  in  doing  flight  planning  and  assembling  crew  papers.  TACC  later  developed 
this  concept  into  a  tool  known  as  the  Sortie  Manager. 

Flight  Visualization  Tool  -  The  label  used  during  FY02  and  FY03  GAMAT  efforts  to  denote  a  generic 
visualization  application  focusing  on  flight  routing  elements.  Multiple  versions  of  this  tool  were 
presented  and  discussed  during  our  FY03  presentations. 

FM  -  Acronym  for  flight  manager. 

FNMOC  -  Acronym  for  ‘Fleet  Numerical  Oceanography  Center’. 
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Foreign  Clearance  Guide  -  The  primary  reference  resource  on  diplomatic  clearances,  and  the  main 
reference  resource  used  by  the  DIP  shop.  This  is  available  in  the  form  of  hardcopy  manuals  physically 
kept  in  the  DIP  shop  work  area. 

FP  -  Acronym  for  flight  planner. 

FPP  -  Acronym  for  Flight  Planning  Palette. 

Front  Office  -  the  label  for  the  single  workstation  in  the  integrated  flight  management  "swimming  pool" 
area  where  one  or  two  WX  staff  members  work  in  closer  collaboration  with  flight  managers  (FM's)  to 
plan  and  monitor  flights. 

FSG  -  Acronym  for  Federated  Software  Group.  FSG  was  the  primary  developer  for  the  Integrated 
Management  Tool  (IMT)  software  addressed  in  the  IFM  project.  They  are  also  the  prime  contractors  for 
developing  TACC's  next-generation  GDSS-2  system. 

FVT  -  Acronym  for  Flight  Visualization  Tool 

G2  -  A  colloquial  shorthand  acronym  sometimes  used  around  AMC  to  refer  to  GDSS-2. 

GAMAT  -  Global  Air  Mobility  Advanced  Technologies.  GAMAT  occurs  as  both  (a)  the  title  of  the 
program  under  which  the  work  reported  here  was  conducted  and  (b)  an  occasional  label  for  the  weather 
visualization  applications  (WCSS-GWM;  WMT)  the  GAMAT  project  had  developed  and  demonstrated 
during  FY02  and  FY03. 

GDSS  -  Global  Decision  Support  System.  The  primary  repository  for  mission  /  sortie  information  from 
the  point  of  completion  of  mission  planning  through  the  execution  phase. 

GDSS  -2  -  Global  Decision  Support  System  2.  The  next-generation  version  of  GDSS,  currently  under 
development  by  FSG.  Sometimes  referred  to  as  'G2'. 

GWM  -  an  acronym  for  'Global  Weather  Management'.  This  label  was  occasionally  used  to  refer  to  the 
Weather  Management  Tool  (WMT)  artifact  prototyped  during  FY02. 

WCSS-GWM  -  an  acronym  for  'Work-Centered  Support  System  for  Global  Weather  Management’.  This 
label  was  used  to  refer  to  the  Weather  Management  Tool  (WMT)  artifact  prototyped  during  the  FY03 
GAMAT  effort. 

HISA  -  Human  Interaction  with  Software  Agents.  This  was  an  AFRL/HES  project  conducted  from  1999 
through  2000,  aimed  at  demonstrating  the  application  of  intelligent  software  agent  technologies  to 
traditional  'shop-based'  AMC/TACC  flight  planning  operations. 

ICAO  -  1.  International  Civil  Aeronautics  Organization.  A  regulatory  organization  overseeing  civil 
aviation  issues  worldwide.  2.  A  shorthand  label  for  the  official  ICAO  code  name  for  a  given  airfield. 
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IFM  -  Integrated  Flight  Management.  This  is  (a)  a  formal  title  for  the  dispatcher  model  of  flight 
planning  /  following  being  implemented  as  a  component  of  AMC's  Mobility  2000  (M2K)  program  and 
(b)  a  general  label  for  a  mode  of  operations  in  which  TACC  staff  serve  as  "dispatchers"  and/or  "virtual 
crew  members"  in  supporting  air  crews. 

IMT  -  Integrated  Management  Tool.  This  is  a  data  integration  application  developed  by  Federated 
Software  Group  (FSG)  and  deployed  as  the  primary  flight  planning  and  following  support  portal  in  the 
"swimming  pool"  within  TACC. 

IMT  Dashboard  -  The  central  interface  component  of  the  Integrated  Management  Tool  (IMT),  consisting 
of  a  large  tabular  display  upon  which  summary  mission  data  is  presented. 

JMPS  -  Joint  Mission  Planning  System.  The  joint  operations  planning  application  (or,  more  accurately, 
suite  of  applications)  toward  which  DOD  is  migrating.  The  system  with  which  our  AMC-based  WCSS 
will  probably  be  required  to  interoperate  if  not  integrate. 

Lead  Time  -  The  amount  of  time  required  prior  to  a  stated  deadline  for  processing  a  DIP  (diplomatic 
clearance)  request. 

Lead  Time  Generator  /  Lead  Time  Calculator  -  Two  informal  labels  used  during  FY03  to  denote  the 
lead  time  notification  /  tracking  capability  incorporated  in  the  ACT  application  being  developed  in 
parallel  by  BBN  Technologies. 

Logbook  -  A  recently-emergent  information  systems  application  in  AMC  /  TACC  which  provides 
personnel  with  a  mutually-accessible  repository  for  notes,  documents,  and  other  data  on  missions.  The 
Logbook  provides  a  location  where  textual  data  on  a  mission  can  be  accreted  and  retrieved.  The 
software  application  affording  the  Logbook  capabilities  to  TACC  is  'DAP'. 

LUI  -  Acronym  for  'Local  User  Interface'.  The  LUI  can  be  described  as  a  dedicated  mini-application 
permitting  TACC  users  to  'remotely'  access  data  resources  not  directly  accessible  from  their  desktops. 
For  example,  the  LUI  provided  flight  managers  (FM's)  with  a  portal  through  which  they  could  access 
ACFP. 

MAR  -  Acronym  for  Mission  Area  Representative. 

Mission  Area  Representative  -  An  emerging  concept  for  a  TACC  task  or  role  which  serves  as  the  liaison 
between  planning  and  execution  by  monitoring  mission  96  hours  prior  through  mission  completion.  The 
vision  is  that  Mission  Area  Representatives  are  planners  that  would  take  over  and  follow  a  mission 
beginning  at  24  hours  prior  to  launch.  As  of  FY03  -  FY04,  the  concept  of  MAR  has  changed  from  the 
WX-specific  version  we  first  encountered  in  our  GAM  AT  FY02  work. 

Mission  Forecaster  -  The  label  denoting  the  front  office  WX  staffer. 

MOG  -  Acronym  for  ‘maximum  on  ground'  -  the  term  for  the  maximum  number  of  aircraft  that  can 
feasibly  be  on-ground  at  a  given  airfield  at  a  given  time. 
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MOG  Master  -  A  label  for  a  position  /  role  that  has  emerged  in  the  execution  cell  at  TACC.  The  MOG 
Master  essentially  works  to  maintain  situation  awareness  over  mission  constraints  and  events  starting 
shortly  before  launch  and  continuing  through  execution.  The  title  notwithstanding,  the  MOG  Master's 
responsibilities  are  not  limited  to  MOG  issues. 

MOG  Viewer  -  A  label  sometimes  given  to  the  Port  Viewer  tool  (originated  in  the  HISA  project)  and/or 
its  multiple  evolutionary  descendants. 

NA TS -  Acronym  for  ‘North  Atlantic  Track  System’. 

Notice  to  Airmen  (NOTAM)  -  An  announcement  issued  by  an  airfield  or  other  authority  to  notify  the 
aviation  community  of  news,  updates,  changes,  restrictions,  etc.,  concerning  access  to  and  operations  of 
a  given  airfield. 

OPS II-  Acronym  for  ‘Operational  Weather  Squadron  Production  System,  Phase  II’. 

ORM- Acronym  for  ‘Operational  Risk  Management’. 

OWS-  Acronym  for  ‘Operational  Risk  Management’. 

PIREP  -  Acronym  for  ‘Pilot  Report’  from  an  aircraft. 

ROO  -  Acronym  for  'Route  Orientation  Officer'. 

SA  -  Acronym  for  'situation  awareness'. 

Shift  Status  Display  -  The  name  given  the  original  WCSS  concept  developed  during  the  IFM  project 
(2000  -  2001)  representing  a  compact  highest-level  overview  over  the  pending  workstream.  The  basic 
form  was  that  of  a  vertically-ordered  set  of  tabs,  each  of  which  identified  a  corresponding  mission  / 
sortie,  provided  minimal  ID  info  on  that  sorties  (arrival  /  departure  ICAO's),  and  a  summary  alert 
indicator  to  cue  the  user  on  that  sortie's  status.  This  concept's  first  prototype  implementation  was  as  an 
auxiliary  feature  of  the  WCSS-GWM  under  the  name  'Sortie  Palette'. 

Sortie  Manager  -  Name  for  a  flight  planning  tool  originally  proposed  under  the  title  'Flight  Planning 
Palette'  at  the  conclusion  of  the  IFM  project  (Spring  2001).  This  concept  was  carried  forward  by  the 
Flight  Managers  and  developed  locally  into  an  actual  application. 

Sortie  Palette  -  The  label  for  the  first  interactive  demo  prototype  of  the  IFM  project's  concept  of  a  'Shift 
Status  Display',  implemented  as  an  auxiliary  feature  associated  with  the  WCSS-GWM. 

Supeiwisor  -  The  local  label  for  the  'lead'  -  the  senior  level  back  office  WX  staffer  with  management  / 
work  tracking  /  threat  assessment  oversight  responsibilities. 

TACC  -  Tanker  Airlift  Control  Center  -  the  primary  transport  flight  operations  component  of  Air 
Mobility  Command  (AMC). 
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Two-Level  (F2)  Database  -  A  label  for  a  concept  developed  by  our  GAMAT  team  during  FY03, 
denoting  a  route  repository  analogous  to  the  current  F2  database  within  which  users  could  index  and 
address  routes  in  terms  of  two  'levels':  (a)  in  terms  of  endpoints  (city-pairs)  and  (b)  in  terms  of 
subsidiary  segments  of  the  route  linking  those  endpoints. 

WCSS  -  Acronym  for  'work-centered  support  system'. 

Weather  Management  Tool  (WMT)  -  one  of  many  labels  used  for  the  agent-based  weather  visualization 
tool  this  project  has  developed  and  demonstrated.  This  tool  has  also  been  referred  to  as  the  "GAMAT 
prototype  and  the  WCSS-GWM". 

WX  -  Acronym  for  "weather". 

WXM  -  Refers  to  TACC/WXM  office,  which  is  the  Weather  Desk  of  the  15th  Operational  Weather 
Squadron. 

XOCZ  -  Refers  to  TACC/XOCZ  office,  which  is  the  International  Flight  Plans  and  Diplomatic 
Clearances  Office. 

XOCZD  -  Refers  to  the  TACC/XOZCD  office,  which  is  the  Diplomatic  Clearance  Division  of  XOCZ. 
XOCZF  -  Refers  to  the  TACC/XOCZF  office,  which  is  the  Flight  Planning  Division  of  XOCZ. 
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Appendix  A:  Illustrative  Survey  of  Nomenclature  Used  for  Flight  /  Route  Elements 


The  first  research  step  in  evaluating  prospects  for  a  coherent  ontology  or  schema  for  categorizing  flight  route  elements  is  to 
survey  what  such  elements  are  currently  defined  and  recognized  in  practice.  The  primary  authority  on  U.S.  aviation 
terminology  is  the  FAA.  This  Appendix  provides  an  overview  of  the  diverse  terms  in  current  use  for  denoting  and  describing 
geospatially-delineated  flight  and  route  elements.  The  terms  below  were  collected  using  the  FAA's  CATS  reference 
database.  Multiple  searches  were  performed  against  the  CATS  online  database  using  keywords  such  as  airway,  route, 
corridor,  segment,  region,  waypoint,  track,  path,  flyway,  sector,  FIR,  airspace,  area,  and  zone. 

The  terms  listed  below  are  not  presumed  to  be  a  comprehensive  enumeration  of  FAA-recognized  route  element 
nomenclature.  However,  they  are  sufficient  to  illustrate  the  range  and  categories  of  nomenclature  in  current  usage.  The 
terms  are  sometimes  subject  to  differential  definitions,  depending  on  which  of  multiple  terminology  sets  they  appear  in.  The 
listings  below  are  tagged  to  indicate  which  of  these  terminology  sets  include  the  given  term  and/or  definition.  For  example, 
'ATC  Glossary'  denotes  the  FAA's  own  Air  Traffic  Control  Glossary;  'ICAO'  denotes  terms  drawn  from  the  nomenclature  of 
the  International  Civilian  Aviation  Organization,  etc. 

ADIZ  (ATC  Glossary).  (See  AIR  DEFENSE  IDENTIFICATION  ZONE.) 

AERODROME  (ATC  Glossary).  A  defined  AREA  on  land  or  water  (including  any  buildings,  installations  and  equipment) 
intended  to  be  used  either  wholly  or  in  part  for  the  arrival,  departure,  and  movement  of  aircraft. 

AERODROME  TRAFFIC  CIRCUIT  [ICAO]  (ATC  Glossary).  The  specified  PATH  to  be  flown  by  aircraft  operating  in 
the  vicinity  of  an  aerodrome. 

AIR  DEFENSE  IDENTIFICATION  ZONE  (ATC  Glossary).  Domestic  Air  Defense  Identification  Zone.  Coastal  Air 
Defense  Identification  Zone.  An  ADIZ  over  the  coastal  waters  of  the  United  States. 

AIRPORT  ADVISORY  AREA  (ATC  Glossary).  The  AREA  within  ten  miles  of  an  airport  without  a  control  tower  or 
where  the  tower  is  not  in  operation,  and  on  which  a  Flight  Service  Station  is  located.  (See  LOCAL  AIRPORT  ADVISORY.) 
(Refer  to  AIM.) 

AIRPORT  (ATC  Glossary).  An  AREA  on  land  or  water  that  is  used  or  intended  to  be  used  for  the  landing  and  takeoff  of 
aircraft  and  includes  its  buildings  and  facilities,  if  any. 

AIRWAY  [ICAO]  (ATC  Glossary).  A  control  area  or  portion  thereof  established  in  the  form  of  corridor  equipped  with 
radio  navigational  aids. 

AIRWAY  (ATC  Glossary).  A  Class  E  airspace  area  established  in  the  form  of  a  corridor,  the  centerline  of  which  is  defined 
by  radio  navigational  aids.  (See  FEDERAL  AIRWAYS.)  (Refer  to  FAR  Part  71 .)  (Refer  to  AIM.) 

AIRWAY  BEACON  (ATC  Glossary).  Used  to  mark  airway  SEGMENTS  in  remote  mountain  areas.  The  light  flashes 
Morse  code  to  identify  the  beacon  site.  (Refer  to  AIM.) 

ALERT  AREA  (ATC  Glossary).  (See  SPECIAL  USE  AIRSPACE.) 

ARRIVAL  SECTOR  (ATC  Glossary).  An  operational  control  SECTOR  containing  one  or  more  meter  fixes. 

ALTERNATE  AERODROME  [ICAO]  (ATC  Glossary).  An  aerodrome  to  which  an  aircraft  may  proceed  when  it 
becomes  either  impossible  or  inadvisable  to  proceed  to  or  to  land  at  the  aerodrome  of  intended  landing.  Note:  The  aerodrome 
from  which  a  flight  departs  may  also  be  an  en-ROUTE  or  a  destination  alternate  aerodrome  for  the  flight. 

ARC  (ATC  Glossary).  The  TRACK  over  the  ground  of  an  aircraft  flying  at  a  constant  distance  from  a  navigational  aid  by 
reference  to  distance  measuring  equipment  (DME). 
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ATC  ASSIGNED  AIRSPACE  (ATC  Glossary).  AIRSPACE  of  defined  vertical/lateral  limits,  assigned  by  ATC,  for  the 
purpose  of  providing  air  traffic  segregation  between  the  specified  activities  being  conducted  within  the  assigned  AIRSPACE 
and  other  IFR  air  traffic.  (See  SPECIAL  USE  AIRSPACE.) 

ATS  Route  [ICAO]  (ATC  Glossary).  A  specified  route  designed  for  channeling  the  flow  of  traffic  as  necessary  for  the 
provision  of  air  traffic  services.  Note:  The  term  "ATS  Route"  is  used  to  mean  variously,  AIRWAY,  advisory  route, 
controlled  or  uncontrolled  route,  arrival  or  departure,  etc. 

BLIND  SPOT  (ATC  Glossary).  An  AREA  from  which  radio  transmissions  and/or  radar  echoes  cannot  be  received.  The 
term  is  also  used  to  describe  portions  of  the  airport  not  visible  from  the  control  tower. 

BLIND  ZONE  (ATC  Glossary).  (See  BLIND  SPOT.) 

CADIZ  (AFTechnet).  CANADIAN  AIR  DEFENSE  IDENTIFICATION  ZONE 

CENTER'S  AREA  (ATC  Glossary).  The  specified  airspace  within  which  an  air  ROUTE  traffic  control  center  (ARTCC) 
provides  air  traffic  control  and  advisory  service.  (See  AIR  ROUTE  TRAFFIC  CONTROL  CENTER.)  (Refer  to  AIM.) 

CHARTED  VFR  FLYWAYS  (ATC  Glossary).  Charted  VFR  Flyways  are  flight  PATHs  recommended  for  use  to  bypass 
areas  heavily  traversed  by  large  turbine-powered  aircraft.  Pilot  compliance  with  recommended  flyways  and  associated 
altitudes  is  strictly  voluntary.  VFR  Flyway  Planning  charts  are  published  on  the  back  of  existing  VFR  Terminal  Area  charts. 

CLASS  A  AIRSPACE  (ATC  Glossary).  (SEE  CONTROLLED  AIRSPACE) 

CLASS  B  AIRSPACE  (ATC  Glossary).  (SEE  CONTROLLED  AIRSPACE) 

CLASS  C  AIRSPACE  (ATC  Glossary).  (SEE  CONTROLLED  AIRSPACE) 

CLASS  D  AIRSPACE  (ATC  Glossary).  (SEE  CONTROLLED  AIRSPACE) 

CLASS  E  AIRSPACE  (ATC  Glossary).  (SEE  CONTROLLED  AIRSPACE) 

CLASS  G  AIRSPACE  (ATC  Glossary).  That  AIRSPACE  not  designated  as  Class  A,  B,  C,  D  or  E. 

CLEARWAY  (ATC  Glossary).  An  AREA  beyond  the  takeoff  runway  under  the  control  of  airport  authorities  within  which 
terrain  or  fixed  obstacles  may  not  extend  above  specified  limits.  These  AREAs  may  be  required  for  certain  turbine-powered 
operations  and  the  size  and  upward  slope  of  the  clearway  will  differ  depending  on  when  the  aircraft  was  certificated.  (Refer 
to  FAR  Part  1 .) 

COASTAL  FIX  (ATC  Glossary).  A  navigation  aid  or  intersection  where  an  aircraft  transitions  between  the  domestic 
ROUTE  structure  and  the  oceanic  ROUTE  structure. 

COMMON  POINT  (ATC  Glossary).  A  significant  point  over  which  two  or  more  aircraft  will  report  passing  or  have 
reported  passing  before  proceeding  on  the  same  or  diverging  TRACKs.  To  establish/maintain  longitudinal  separation,  a 
controller  may  determine  a  common  point  not  originally  in  the  aircraft’s  flight  plan  and  then  clear  the  aircraft  to  fly  over  the 
point.  (See  SIGNIFICANT  POINT.) 

COMMON  ROUTE  (ATC  Glossary).  That  SEGMENT  of  a  North  American  Route  between  the  inland  navigation  facility 
and  the  coastal  fix. 

COMPOSITE  ROUTE  SYSTEM  (ATC  Glossary).  An  organized  oceanic  ROUTE  structure,  incorporating  reduced  lateral 
spacing  between  ROUTES,  in  which  composite  separation  is  authorized. 
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COMPULSORY  REPORTING  POINTS  (ATC  Glossary).  Reporting  points  which  must  be  reported  to  ATC.  They  are 
designated  on  aeronautical  charts  by  solid  triangles  or  filed  in  a  flight  plan  as  fixes  selected  to  define  direct  ROUTEs.  Pilots 
should  discontinue  position  reporting  over  compulsory  reporting  points  when  informed  by  ATC  that  their  aircraft  is  in  "radar 
contact." 

CONTROL  AREA  [ICAO]  (ATC  Glossary).  A  controlled  AIRSPACE  extending  upwards  from  a  specified  limit  above 
the  earth. 

CONTROL  SECTOR  (ATC  Glossary).  An  airspace  area  of  defined  horizontal  and  vertical  dimensions  for  which  a 
controller  or  group  of  controllers  has  air  traffic  control  responsibility,  normally  within  an  air  ROUTE  traffic  control  center  or 
an  approach  control  facility.  Sectors  are  established  based  on  predominant  traffic  flows,  altitude  strata,  and  controller 
workload.  Pilot-communications  during  operations  within  a  sector  are  normally  maintained  on  discrete  frequencies  assigned 
to  the  sector. 

CONTROLLED  AIRSPACE  [ICAO]  (ATC  Glossary).  An  AIRSPACE  of  defined  dimensions  within  which  air  traffic 
control  service  is  provided  to  IFR  flights  and  to  VFR  flights  in  accordance  with  the  AIRSPACE  classification.  (Note: 
Controlled  AIRSPACE  is  a  generic  term  which  covers  ATS  AIRSPACE  Classes  A,  B,  C,  D,  and  E.) 

CONTROLLED  AIRSPACE  (ATC  Glossary).  An  AIRSPACE  of  defined  dimensions  within  which  air  traffic  control 
service  is  provided  to  IFR  flights  and  to  VFR  flights  in  accordance  with  the  AIRSPACE  classification.  Controlled 
AIRSPACE  is  a  generic  term  that  covers  Class  A,  Class  B,  Class  C,  Class  D,  and  Class  E  AIRSPACE.  5.  CLASS  E 
Generally,  if  the  AIRSPACE  is  not  Class  A,  Class  B,  Class  C,  or  Class  D,  and  it  is  controlled  AIRSPACE,  it  is  Class  E 
AIRSPACE. 

COURSE  (ATC  Glossary).  The  intended  direction  of  flight  in  the  horizontal  plane  measured  in  degrees  from  north.  The 
ILS  localizer  signal  pattern  usually  specified  as  the  front  course  or  the  back  course.  The  intended  track  along  a  straight, 
curved,  or  SEGMENTed  MLS  path. 

DANGER  AREA  [ICAO]  (ATC  Glossary).  An  AIRSPACE  of  defined  dimensions  within  which  activities  dangerous  to 
the  flight  of  aircraft  may  exist  at  specified  times.  Note:  The  term  "Danger  Area"  is  not  used  in  reference  to  areas  within  the 
United  States  or  any  of  its  possessions  or  territories. 

DESIRED  TRACK  (ATC  Glossary).  The  planned  or  intended  track  between  two  WAYPOINTs.  It  is  measured  in  degrees 
from  either  magnetic  or  true  north.  The  instantaneous  angle  may  change  from  point  to  point  along  the  great  circle  track 
between  WAYPOINTs. 

DEWIS  (AFTechnet).  DISTANT  EARLY  WARNING  ZONE 
DEWIZ  (TAG).  Distance  Early  Warning  Identification  ZONE 

DIRECT  (ATC  Glossary).  Straight  line  flight  between  two  navigational  aids,  fixes,  points,  or  any  combination  thereof. 
When  used  by  pilots  in  describing  off-airway  routes,  points  defining  direct  route  SEGMENTS  become  compulsory  reporting 
points  unless  the  aircraft  is  under  radar  contact. 

DIVERSE  VECTOR  AREA  (ATC  Glossary).  In  a  radar  environment,  that  area  in  which  a  prescribed  departure  ROUTE  is 
not  required  as  the  only  suitable  ROUTE  to  avoid  obstacles.  The  area  in  which  random  radar  vectors  below  the  MV  A/MIA, 
established  in  accordance  with  the  TERPS  criteria  for  diverse  departures,  obstacles  and  terrain  avoidance,  may  be  issued  to 
departing  aircraft. 

DOMESTIC  AIRSPACE  (ATC  Glossary).  AIRSPACE  which  overlies  the  continental  land  mass  of  the  United  States  plus 
Hawaii  and  U.S.  possessions.  Domestic  AIRSPACE  extends  to  12  miles  offshore. 

DSUA  (TAG).  Dynamic  Special  -  Use  AIRSPACE 

DSUA  (AFTechnet).  Dynamic  Special  Use  AIRSPACE 
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DVA  (ATC  Glossary).  (See  DIVERSE  VECTOR  AREA.) 


FEEDER  FIX  (ATC  Glossary).  The  fix  depicted  on  Instrument  Approach  Procedure  Charts  which  establishes  the  starting 
point  of  the  feeder  ROUTE. 

FEEDER  ROUTE  (ATC  Glossary).  A  ROUTE  depicted  on  instrument  approach  procedure  charts  to  designate  ROUTEs 
for  aircraft  to  proceed  from  the  en  ROUTE  structure  to  the  initial  approach  fix  (IAF).  (See  INSTRUMENT  APPROACH 
PROCEDURE.) 

FINAL  APPROACH  COURSE  (ATC  Glossary).  A  bearing/radial/TRACK  of  an  instrument  approach  leading  to  a  runway 
or  an  extended  runway  centerline  all  without  regard  to  distance. 

FINAL  APPROACH  FIX  (ATC  Glossary).  The  fix  from  which  the  final  approach  (IFR)  to  an  airport  is  executed  and 
which  identifies  the  beginning  of  the  final  approach  SEGMENT.  It  is  designated  on  Government  charts  by  the  Maltese  Cross 
symbol  for  nonprecision  approaches  and  the  lightning  bolt  symbol  for  precision  approaches;  or  when  ATC  directs  a  lower- 
than-published  glideslope/path  intercept  altitude,  it  is  the  resultant  actual  point  of  the  glideslope/path  intercept.  (See 
SEGMENTS  OF  AN  INSTRUMENT  APPROACH  PROCEDURE.) 

FINAL  APPROACH  POINT  (ATC  Glossary).  The  point,  applicable  only  to  a  nonprecision  approach  with  no  depicted 
FAF  (such  as  an  on  airport  VOR),  where  the  aircraft  is  established  inbound  on  the  final  approach  course  from  the  procedure 
turn  and  where  the  final  approach  descent  may  be  commenced.  The  FAP  serves  as  the  FAF  and  identifies  the  beginning  of 
the  final  approach  SEGMENT.  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH  PROCEDURE.) 

FINAL  APPROACH  SEGMENT  [ICAO]  (ATC  Glossary).  That  SEGMENT  of  an  instrument  approach  procedure  in 
which  alignment  and  descent  for  landing  are  accomplished. 

FINAL  APPROACH  SEGMENT  (ATC  Glossary).  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH 
PROCEDURE.) 

FINAL  APPROACH-IFR  (ATC  Glossary).  The  flight  path  of  an  aircraft  which  is  inbound  to  an  airport  on  a  final 
instrument  approach  course,  beginning  at  the  final  approach  fix  or  point  and  extending  to  the  airport  or  the  point  where  a 
circle-to-land  maneuver  or  a  missed  approach  is  executed.  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH 
PROCEDURE.)  (See  ICAO  term  FINAL  APPROACH.) 

FIR  (ATC  Glossary).  (See  FLIGHT  INFORMATION  REGION.) 

FLIGHT  INFORMATION  REGION  (ATC  Glossary).  An  AIRSPACE  of  defined  dimensions  within  which  Flight 
Information  Service  and  Alerting  Service  are  provided.  A  service  provided  for  the  purpose  of  giving  advice  and  information 
useful  for  the  safe  and  efficient  conduct  of  flights.  A  service  provided  to  notify  appropriate  organizations  regarding  aircraft  in 
need  of  search  and  rescue  aid  and  to  assist  such  organizations  as  required. 

FLIGHT  PATH  (ATC  Glossary).  A  line,  course,  or  TRACK  along  which  an  aircraft  is  flying  or  intended  to  be  flown.  (See 
TRACK.)  (See  COURSE.) 

FLIGHT  PLAN  AREA  (ATC  Glossary).  The  geographical  AREA  assigned  by  regional  air  traffic  divisions  to  a  flight 
service  station  for  the  purpose  of  search  and  rescue  for  VFR  aircraft,  issuance  of  NOT AMs,  pilot  briefing,  in-flight  services, 
broadcast,  emergency  sendees,  flight  data  processing,  international  operations,  and  aviation  weather  services.  Three  letter 
identifiers  are  assigned  to  every  flight  service  station  and  are  annotated  in  AFD's  and  FAA  Order  7350.6,  LOCATION 
IDENTIFIERS,  as  tie-in-facilities.  (See  FAST  FILE.) 

FLY-BY  WAYPOINT  (ATC  Glossary).  A  fly  by  waypoint  requires  the  use  of  turn  anticipation  to  avoid  overshoot  of  the 
next  flight  SEGMENT. 

FLY-OVER  WAYPOINT  (ATC  Glossary).  A  fly-over  waypoint  precludes  any  turn  until  the  waypoint  is  overflown  and  is 
followed  by  an  intercept  maneuver  of  the  next  flight  SEGMENT. 
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GAOC  (ZAB  Acronym  List).  GEOGRAPHIC  AREA  OF  CONCERN 

HIWAS  AREA  (ATC  Glossary).  (See  HAZARDOUS  INFLIGHT  WEATHER  ADVISORY  SERVICE.) 

HIWAS  BROADCAST  AREA  (ATC  Glossary).  A  geographical  AREA  of  responsibility  including  one  or  more  HIWAS 
outlet  AREAs  assigned  to  an  AFSS/FSS  for  hazardous  weather  advisory  broadcasting. 

HIWAS  OUTLET  AREA  (ATC  Glossary).  An  AREA  defined  as  a  150  NM  radius  of  a  HIWAS  outlet,  expanded  as 
necessary  to  provide  coverage. 

IFR  MILITARY  TRAINING  ROUTES  (IR)  (ATC  Glossary).  ROUTEs  used  by  the  Department  of  Defense  and 
associated  Reserve  and  Air  Guard  units  for  the  purpose  of  conducting  low-altitude  navigation  and  tactical  training  in  both 
IFR  and  VFR  weather  conditions  below  10,000  feet  MSL  at  airspeeds  in  excess  of  250  knots  IAS. 

INITIAL  APPROACH  FIX  (ATC  Glossary).  The  fixes  depicted  on  instrument  approach  procedure  charts  that  identify  the 
beginning  of  the  initial  approach  SEGMENT(s).  (See  FIX.)  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH 
PROCEDURE.) 

INITIAL  APPROACH  SEGMENT  [ICAO]  (ATC  Glossary).  That  SEGMENT  of  an  instrument  approach  procedure 
between  the  initial  approach  fix  and  the  intermediate  approach  fix  or,  where  applicable,  the  final  approach  fix  or  point. 

INITIAL  APPROACH  SEGMENT  (ATC  Glossary).  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH 
PROCEDURE.) 

INTERMEDIATE  APPROACH  SEGMENT  [ICAO]  (ATC  Glossary).  That  SEGMENT  of  an  instrument  approach 
procedure  between  either  the  intermediate  approach  fix  and  the  final  approach  fix  or  point,  or  between  the  end  of  a  reversal, 
race  track  or  dead  reckoning  track  procedure  and  the  final  approach  fix  or  point,  as  appropriate. 

INTERMEDIATE  FIX  (ATC  Glossary).  The  fix  that  identifies  the  beginning  of  the  intermediate  approach  SEGMENT  of 
an  instrument  approach  procedure.  The  fix  is  not  normally  identified  on  the  instrument  approach  chart  as  an  intermediate  fix 
(IF).  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH  PROCEDURE.) 

IF/IAWP  (ATC  Glossary).  Intermediate  Fix/Initial  Approach  WAYPOINT.  The  WAYPOINT  where  the  final  approach 
course  of  a  T  approach  meets  the  crossbar  of  the  T.  When  designated  (in  conjunction  with  a  TAA)  this  WAYPOINT  will  be 
used  as  an  IAWP  when  approaching  the  airport  from  certain  directions,  and  as  an  IFWP  when  beginning  the  approach  from 
another  IAWP. 

JET  ROUTE  (ATC  Glossary).  A  ROUTE  designed  to  serve  aircraft  operations  from  18,000  feet  MSL  up  to  and  including 
flight  level  450.  The  ROUTEs  are  referred  to  as  "J"  ROUTEs  with  numbering  to  identify  the  designated  ROUTE;  e.g.,  J105. 
(See  Class  A  AIRSPACE.)  (Refer  to  FAR  Part  71.) 

JOINT  USE  RESTRICTED  AREA  (ATC  Glossary).  (See  RESTRICTED  AREA.) 

LANDING  AREA  [ICAOj  (ATC  Glossary).  That  part  of  a  movement  AREA  intended  for  the  landing  or  takeoff  of 
aircraft. 

LANDING  AREA  (ATC  Glossary).  Any  locality  either  on  land,  water,  or  structures,  including  airports/heliports  and 
intermediate  landing  fields,  which  is  used,  or  intended  to  be  used,  for  the  landing  and  takeoff  of  aircraft  whether  or  not 
facilities  are  provided  for  the  shelter,  servicing,  or  for  receiving  or  discharging  passengers  or  cargo.  (See  ICAO  term 
LANDING  AREA.) 

LOW  ALTITUDE  AIRWAY  STRUCTURE  (ATC  Glossary).  The  network  of  AIRWAYs  serving  aircraft  operations  up 
to  but  not  including  18,000  feet  MSL.  (See  AIRWAY.)  (Refer  to  AIM.) 
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METERING  FIX  (ATC  Glossary).  A  fix  along  an  established  ROUTE  from  over  which  aircraft  will  be  metered  prior  to 
entering  terminal  airspace.  Normally,  this  fix  should  be  established  at  a  distance  from  the  airport  which  will  facilitate  a 
profile  descent  10,000  feet  above  airport  elevation  [AAE]  or  above. 

MILITARY  OPERATIONS  AREA  (ATC  Glossary).  (See  SPECIAL  USE  AIRSPACE.) 

MILITARY  TRAINING  ROUTES  (ATC  Glossary).  Airspace  of  defined  vertical  and  lateral  dimensions  established  for 
the  conduct  of  military  flight  training  at  airspeeds  in  excess  of  250  knots  IAS.  (See  IFR  MILITARY  TRAINING  ROUTES.) 
(See  VFR  MILITARY  TRAINING  ROUTES.) 

MINIMUM  NAVIGATION  PERFORMANCE  SPECIFICATIONS  AIRS  (ATC  Glossary).  Designated  airspace  in 
which  MNPS  procedures  are  applied  between  MNPS  certified  and  equipped  aircraft.  Under  certain  conditions,  non-MNPS 
aircraft  can  operate  in  MNPSA.  However,  a  standard  oceanic  separation  minimum  is  provided  between  the  non-MNPS 
aircraft  and  other  traffic. 

MISSED  APPROACH  POINT  (ATC  Glossary).  A  point  prescribed  in  each  instrument  approach  procedure  at  which  a 
missed  approach  procedure  shall  be  executed  if  the  required  visual  reference  does  not  exist.  (See  MISSED  APPROACH.) 
(See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH  PROCEDURE.) 

MISSED  APPROACH  SEGMENT  (ATC  Glossary).  (See  SEGMENTS  OF  AN  INSTRUMENT  APPROACH 
PROCEDURE.) 

MOA  (ATC  Glossary).  (See  MILITARY  OPERATIONS  AREA.) 

MOA  (TAG).  Military  Operations  AREA 

MOVEMENT  AREA  [ICAO]  (ATC  Glossary).  That  part  of  an  aerodrome  to  be  used  for  the  takeoff,  landing  and  taxiing 
of  aircraft,  consisting  of  the  maneuvering  AREA  and  the  apron(s). 

MOVEMENT  AREA  (ATC  Glossary).  The  runways,  taxiways,  and  other  AREAs  of  an  airport/heliport  which  are  utilized 
for  taxiing/hover  taxiing,  air  taxiing,  takeoff,  and  landing  of  aircraft,  exclusive  of  loading  ramps  and  parking  AREAs.  At 
those  airports/heliports  with  a  tower,  specific  approval  for  entry  onto  the  movement  AREA  must  be  obtained  from  ATC.  (See 
ICAO  term  MOVEMENT  AREA.) 

NATIONAL  AIRSPACE  SYSTEM  (ATC  Glossary).  The  common  network  of  U.S.  AIRSPACE;  air  navigation  facilities, 
equipment  and  services,  airports  or  landing  areas;  aeronautical  charts,  information  and  services;  rules,  regulations  and 
procedures,  technical  information,  and  manpower  and  material.  Included  are  system  components  shared  jointly  with  the 
military. 

NATIONAL  BEACON  CODE  ALLOCATION  PLAN  AIRSPACE  (ATC  Glossary).  Airspace  over  United  States 
territory  located  within  the  North  American  continent  between  Canada  and  Mexico,  including  adjacent  territorial  waters 
outward  to  about  boundaries  of  oceanic  control  areas  (CTA)/Flight  Information  Regions  (FIR).  (See  FLIGHT 
INFORMATION  REGION.) 

NAVIGABLE  AIRSPACE  (ATC  Glossary).  AIRSPACE  at  and  above  the  minimum  flight  altitudes  prescribed  in  the 
FAR's  including  AIRSPACE  needed  for  safe  takeoff  and  landing.  (Refer  to  FAR  Part  9 1 .) 

NBCAP  AIRSPACE  (ATC  Glossary).  (See  NATIONAL  BEACON  CODE  ALLOCATION  PLAN  AIRSPACE.) 

NO  GYRO  APPROACH  (ATC  Glossary).  A  radar  approach/vector  provided  in  case  of  a  malfunctioning  gyro-compass  or 
directional  gyro.  Instead  of  providing  llie  pilot  with  headings  to  be  flown,  the  controller  observes  the  radar  TRACK  and 
issues  control  instructions  "turn  right/left"  or  "stop  turn"  as  appropriate.  (Refer  to  AIM.) 


120 


NO  TRANSGRESSION  ZONE  (NTZ)  (ATC  Glossary).  The  NTZ  is  a  2,000  foot  wade  ZONE,  located  equidistant 
between  parallel  runway  final  approach  courses  in  which  flight  is  not  allowed. 

NONCOMMON  ROUTE/PORTION  (ATC  Glossary).  That  SEGMENT  of  a  North  American  Route  between  the  inland 
navigation  facility  and  a  designated  North  American  terminal. 

NONMOVEMENT  AREAS  (ATC  Glossary).  Taxiways  and  apron  (ramp)  AREAs  not  under  the  control  of  air  traffic. 

NORMAL  OPERATING  ZONE  (NOZ)  (ATC  Glossary).  The  NOZ  is  the  operating  ZONE  within  which  aircraft  flight 
remains  during  normal  independent  simultaneous  parallel  ILS  approaches. 

NORTH  AMERICAN  ROUTE  (ATC  Glossary).  A  numerically  coded  route  preplanned  over  existing  airway  and  route 
systems  to  and  from  specific  coastal  fixes  serving  the  North  Atlantic.  That  SEGMENT  of  a  North  American  Route  between 
the  inland  navigation  facility  and  the  coastal  fix.  That  SEGMENT  of  a  North  American  Route  between  the  inland  navigation 
facility  and  a  designated  North  American  terminal. 

NORTH  PACIFIC  (ATC  Glossary).  An  organized  ROUTE  system  between  the  Alaskan  west  coast  and  Japan. 

NTZ  (AFTechnet).  No  Transgression  ZONE 

OBSTACLE  FREE  ZONE  (ATC  Glossary).  The  runway  OFZ  and  when  applicable,  the  inner-approach  OFZ,  and  the 
inner-transitional  OFZ,  comprise  the  OFZ.  The  runway  OFZ  is  a  defined  volume  of  AIRSPACE  centered  above  the  runway. 
The  runway  OFZ  extends  200  feet  beyond  each  end  of  the  runway. 

OCA  (AFTechnet).  OCEANIC  CONTROL  AREA 

OCEANIC  AIRSPACE  (ATC  Glossary).  AIRSPACE  over  the  oceans  of  the  world,  considered  international  AIRSPACE, 
where  oceanic  separation  and  procedures  per  the  International  Civil  Aviation  Organization  are  applied.  Responsibility  for  the 
provisions  of  air  traffic  control  service  in  this  AIRSPACE  is  delegated  to  various  countries,  based  generally  upon  geographic 
proximity  and  the  availability  of  the  required  resources. 

OCEANIC  PUBLISHED  ROUTE  (ATC  Glossary).  A  route  established  in  international  airspace  and  charted  or  described 
in  flight  information  publications,  such  as  Route  Charts,  DOD  Enroute  Charts,  Chart  Supplements,  NOTAM’s,  and  TRACK 
Messages. 

OCEANIC  TRANSITION  ROUTE  (ATC  Glossary).  An  ATS  route  established  for  the  purpose  of  transitioning  aircraft 
to/from  an  organized  TRACK  system. 

OFA  (TAG).  Object  Free  AREA 

OFFSHORE  CONTROL  AREA  (ATC  Glossary').  That  portion  of  airspace  between  the  U.S.  12-mile  limit  and  the  oceanic 
CTA/FIR  boundary  within  which  air  traffic  control  is  exercised.  These  areas  are  established  to  permit  the  application  of 
domestic  procedures  in  the  provision  of  air  traffic  control  sendees.  Offshore  control  area  is  generally  synonymous  with 
Federal  Aviation  Regulations,  FAR  Part  71,  Subpart  E,  "Control  Areas  and  Control  Area  Extensions." 

OFZ  (TAG).  Obstacle  Free  ZONE 

ORGANIZED  TRACK  SYSTEM  (ATC  Glossary).  A  series  of  ATS  routes  which  are  fixed  and  charted;  i.e.,  CEP, 
NOPAC,  or  flexible  and  described  by  NOTAM;  i.e.,  NAT  TRACK  MESSAGE. 

ORGANIZED  TRACK  SYSTEM  (ATC  Glossary).  A  movable  system  of  oceanic  TRACKs  that  traverses  the  North 
Atlantic  between  Europe  and  North  America  the  physical  position  of  which  is  determined  twdee  daily  taking  the  best 
advantage  of  the  winds  aloft. 
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OUTER  AREA  (ATC  Glossary),  (associated  with  Class  C  AIRSPACE)  Nonregulatory  AIRSPACE  surrounding 
designated  Class  C  AIRSPACE  airports  wherein  ATC  provides  radar  vectoring  and  sequencing  on  a  full-time  basis  for  all 
IFR  and  participating  VFR  aircraft.  The  service  provided  in  the  outer  area  is  called  Class  C  service  which  includes:  IFR/IFR- 
standard  IFR  separation;  IFR/VFR-traffic  advisories  and  conflict  resolution;  and  VFR/VFR-traffic  advisories  and,  as 
appropriate,  safety  alerts. 

OUTER  FIX  (ATC  Glossary).  An  adapted  fix  along  the  converted  ROUTE  of  flight,  prior  to  the  meter  fix,  for  which 
crossing  times  are  calculated  and  displayed  in  the  metering  position  list. 

OUTER  FIX  (ATC  Glossary).  A  general  term  used  within  ATC  to  describe  fixes  in  the  terminal  area,  other  than  the  final 
approach  fix.  Aircraft  are  normally  cleared  to  these  fixes  by  an  Air  ROUTE  Traffic  Control  Center  or  an  Approach  Control 
Facility.  Aircraft  are  normally  cleared  from  these  fixes  to  the  final  approach  fix  or  final  approach  course. 

PARALLEL  OFFSET  ROUTE  (ATC  Glossary).  A  parallel  TRACK  to  the  left  or  right  of  the  designated  or  established 
airway/route.  Normally  associated  with  Area  Navigation  (RNAV)  operations.  (See  AREA  NAVIGATION.) 

PCA  (TAG).  Positive  Control  AIRSPACE 

POLAR  TRACK  STRUCTURE  (ATC  Glossary).  A  system  of  organized  routes  between  Iceland  and  Alaska  which 
overlie  Canadian  MNPS  Airspace. 

PREFERENTIAL  ROUTES  (ATC  Glossary).  Locations  having  a  need  for  these  specific  inbound  and  outbound  ROUTES 
normally  publish  such  ROUTEs  in  local  facility  bulletins,  and  their  use  by  pilots  minimizes  flight  plan  ROUTE  amendments. 
It  may  be  included  in  a  Standard  Instrument  Departure  (SID)  or  a  Preferred  IFR  ROUTE.  It  may  be  included  in  a  Standard 
Terminal  Arrival  (STAR)  or  a  Preferred  IFR  ROUTE. 

PREFERRED  IFR  ROUTES  (ATC  Glossary).  Routes  established  between  busier  airports  to  increase  system  efficiency 
and  capacity.  Preferred  IFR  Routes  are  listed  in  the  Airport/Facility  Directory.  Preferred  IFR  Routes  are  correlated  with  SID's 
and  STAR'S  and  may  be  defined  by  airways,  jet  routes,  direct  routes  between  NAVAID's,  WAYPOINTs,  NAVAID 
radials/DME,  or  any  combinations  thereof. 

PROHIBITED  AREA  [ICAO]  (ATC  Glossary).  An  AIRSPACE  of  defined  dimensions,  above  the  land  areas  or  territorial 
waters  of  a  State,  within  which  the  flight  of  aircraft  is  prohibited. 

PROHIBITED  AREA  (ATC  Glossary).  (See  SPECIAL  USE  AIRSPACE.)  (See  ICAO  term  PROHIBITED  AREA.) 

PROTECTED  AIRSPACE  (ATC  Glossary).  The  AIRSPACE  on  either  side  of  an  oceanic  route/track  that  is  equal  to  one- 
half  the  lateral  separation  minimum  except  where  reduction  of  protected  AIRSPACE  has  been  authorized. 

PROTECTED  AIRSPACE  (ATC  Glossary).  The  airspace  on  either  side  of  an  oceanic  route/TRACK  that  is  equal  to  one- 
half  the  lateral  separation  minimum  except  where  reduction  of  protected  airspace  has  been  authorized. 

PUBLISHED  ROUTE  (ATC  Glossary).  A  route  for  which  an  IFR  altitude  has  been  established  and  published;  e.g., 
Federal  AIRWAYs,  Jet  Routes,  Area  Navigation  Routes,  Specified  Direct  Routes. 

RADAR  ENVIRONMENT  (ATC  Glossary).  An  AREA  in  which  radar  service  may  be  provided.  (See  ADDITIONAL 
SERVICES.)  (See  RADAR  CONTACT.) 

RADAR  ROUTE  (ATC  Glossary).  A  flight  PATH  or  route  over  which  an  aircraft  is  vectored.  Navigational  guidance  and 
altitude  assignments  are  provided  by  ATC.  (See  FLIGHT  PATH.) 

RANDOM  ROUTE  (ATC  Glossary).  Any  ROUTE  not  established  or  charted/published  or  not  otherwise  available  to  all 
users. 
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RESTRICTED  AREA  [ICAO]  (ATC  Glossary).  An  AIRSPACE  of  defined  dimensions,  above  the  land  areas  or  territorial 
waters  of  a  State,  within  which  the  flight  of  aircraft  is  restricted  in  accordance  with  certain  specified  conditions. 

RESTRICTED  AREA  (ATC  Glossary).  (See  SPECIAL  USE  AIRSPACE.)  (See  ICAO  term  RESTRICTED  AREA.) 

ROUTE  (ATC  Glossary).  A  defined  PATH,  consisting  of  one  or  more  courses  in  a  horizontal  plane,  which  aircraft  traverse 
over  the  surface  of  the  earth.  (See  JET  ROUTE.)  (See  PUBLISHED  ROUTE.) 

ROUTE  SEGMENT  (ICAO)  (ATC  Glossary).  A  portion  of  a  route  to  be  flown,  as  defined  by  two  consecutive  significant 
points  specified  in  a  flight  plan. 

ROUTE  SEGMENT  (ATC  Glossary).  As  used  in  Air  Traffic  Control,  a  part  of  a  route  that  can  be  defined  by  two 
navigational  fixes,  two  NAVAID’s,  or  a  fix  and  a  NAVAID.  (See  FIX.)  (See  ICAO  term  ROUTE  SEGMENT.) 

RUNWAY  SAFETY  AREA  (ATC  Glossary).  A  defined  surface  surrounding  the  runway  prepared,  or  suitable,  for 
reducing  the  risk  of  damage  to  airplanes  in  the  event  of  an  undershoot,  overshoot,  or  excursion  from  the  runway.  The 
dimensions  of  the  RSA  vary  and  can  be  determined  by  using  the  criteria  contained  within  the  Federal  Aviation 
Administration,  Airport  Advisory  Circular  Number:  AC  150/5300-13,  Airport  Design,  Chapter  3.  Figure  3-1  in  AC 
150/5300-13  depicts  the  RSA.  Capable,  under  dry  conditions,  of  supporting  snow  removal  equipment,  aircraft  rescue  and 
firefighting  equipment,  and  the  occasional. 

RUNWAY  (ATC  Glossary).  A  defined  rectangular  AREA  on  a  land  airport  prepared  for  the  landing  and  takeoff  run  of 
aircraft  along  its  length.  Runways  are  normally  numbered  in  relation  to  their  magnetic  direction  rounded  off  to  the  nearest  10 
degrees;  e.g.,  Runway  01,  Runway  25.  (See  PARALLEL  RUNWAYS.)  (See  ICAO  term  RUNWAY.) 

SEGMENTS  OF  AN  INSTRUMENT  APPROACH  PROCEDURE  (ATC  Glossary).  Initial  Approach  the  SEGMENT 
between  the  initial  approach  fix  and  the  intermediate  fix  or  the  point  where  the  aircraft  is  established  on  the  intermediate 
course  or  final  approach  course.  Intermediate  Approach  the  SEGMENT  between  the  intermediate  fix  or  point  and  the  final 
approach  fix.  Final  Approach  the  SEGMENT  between  the  final  approach  fix  or  point  and  the  runway,  airport,  or  missed 
approach  point. 

SIGNIFICANT  POINT  (ATC  Glossary).  A  point,  whether  a  named  intersection,  a  NAVAID,  a  fix  derived  from  a 
NAVAID(s),  or  geographical  coordinate  expressed  in  degrees  of  latitude  and  longitude,  which  is  established  for  the  purpose 
of  providing  separation,  as  a  reporting  point,  or  to  delineate  a  ROUTE  of  flight. 

SINGLE  DIRECTION  ROUTES  (ATC  Glossary).  Preferred  IFR  ROUTEs  which  are  sometimes  depicted  on  high  altitude 
en  ROUTE  charts  and  which  are  normally  flown  in  one  direction  only.  (See  PREFERRED  IFR  ROUTES.)  (Refer  to 
AIRPORT/FACILITY  DIRECTORY.) 

SPECIAL  USE  AIRSPACE  (ATC  Glossary).  Alert  Area  Airspace  which  may  contain  a  high  volume  of  pilot  training 
activities  or  an  unusual  type  of  aerial  activity,  neither  of  which  is  hazardous  to  aircraft.  Controlled  Firing  Area  Airspace 
wherein  activities  are  conducted  under  conditions  so  controlled  as  to  eliminate  hazards  to  nonparticipating  aircraft  and  to 
ensure  the  safety  of  persons  and  property  on  the  ground.  Prohibited  Area  Airspace  designated  under  part  73  within  which  no 
person  may  operate  an  aircraft  without  the  permission. 

SPEED  SEGMENTS  (ATC  Glossary).  Portions  of  the  arrival  route  between  the  transition  point  and  the  vertex  along  the 
optimum  flight  path  for  which  speeds  and  altitudes  are  specified.  There  is  one  set  of  arrival  speed  SEGMENTS  adapted  from 
each  transition  point  to  each  vertex.  Each  set  may  contain  up  to  six  SEGMENTS. 

STEPDOWN  FIX  (ATC  Glossary).  A  fix  permitting  additional  descent  within  a  SEGMENT  of  an  instrument  approach 
procedure  by  identifying  a  point  at  which  a  controlling  obstacle  has  been  safely  overflown. 

STEREO  ROUTE  (ATC  Glossary).  A  routinely  used  ROUTE  of  flight  established  by  users  and  ARTCC's  identified  by  a 
coded  name;  e.g.,  ALPHA  2.  These  ROUTEs  minimize  flight  plan  handling  and  communications. 
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STOPWAY  (ATC  Glossary).  An  AREA  beyond  the  takeoff  runway  no  less  wide  than  the  runway  and  centered  upon  the 
extended  centerline  of  the  runway,  able  to  support  the  airplane  during  an  aborted  takeoff,  without  causing  structural  damage 
to  the  airplane,  and  designated  by  the  airport  authorities  for  use  in  decelerating  the  airplane  during  an  aborted  takeoff. 

SUA  (NAS  Architecture  4).  Special  use  AIRSPACE 

SUBSTITUTE  ROUTE  (ATC  Glossary).  A  route  assigned  to  pilots  when  any  part  of  an  AIRWAY  or  route  is  unusable 
because  of  NAVAID  status.  These  routes  consist  of  Routes  defined  by  ATC  as  specific  NAVAID  radials  or  courses. 

SURFACE  AREA  (ATC  Glossary).  The  AIRSPACE  contained  by  the  lateral  boundary  of  the  Class  B,  C,  D,  or  E 
AIRSPACE  designated  for  an  airport  that  begins  at  the  surface  and  extends  upward. 

TERMINAL  AREA  (ATC  Glossary).  A  general  term  used  to  describe  AIRSPACE  in  which  approach  control  service  or 
airport  traffic  control  service  is  provided. 

TERMINAL  AREA  FACILITY  (ATC  Glossary).  A  facility  providing  air  traffic  control  service  for  arriving  and  departing 
IFR,  VFR,  Special  VFR,  and  on  occasion  en  route'aircraft.  (See  APPROACH  CONTROL  FACILITY.)  (See  TOWER.) 

TERMINAL  RADAR  SERVICE  AREA  (ATC  Glossary).  AIRSPACE  surrounding  designated  airports  wherein  ATC 
provides  radar  vectoring,  sequencing,  and  separation  on  a  full-time  basis  for  all  IFR  and  participating  VFR  aircraft.  Service 
provided  in  a  TRSA  is  called  Stage  III  Service.  The  AIM  contains  an  explanation  of  TRSA. 

TOUCHDOWN  [ICAO]  (ATC  Glossary).  The  point  where  the  nominal  glide  PATH  intercepts  the  runway.  Note: 
Touchdown  as  defined  above  is  only  a  datum  and  is  not  necessarily  the  actual  point  at  which  the  aircraft  will  touch  the 
runway. 

TOUCHDOWN  (ATC  Glossary).  The  point  at  which  an  aircraft  first  makes  contact  with  the  landing  surface.  Concerning  a 
precision  radar  approach  (PAR),  it  is  the  point  where  the  glide  PATH  intercepts  the  landing  surface.  (See  ICAO  term 
TOUCHDOWN.) 

TOUCHDOWN  ZONE  [ICAO]  (ATC  Glossary).  The  portion  of  a  runway,  beyond  the  threshold,  where  it  is  intended 
landing  aircraft  first  contact  the  runway. 

TOUCHDOWN  ZONE  (ATC  Glossary).  The  first  3,000  feet  of  the  runway  beginning  at  the  threshold.  The  AREA  is  used 
for  determination  of  Touchdown  Zone  Elevation  in  the  development  of  straight-in  landing  minimums  for  instrument 
approaches.  (See  ICAO  term  TOUCHDOWN  ZONE.) 

TRACK  [ICAO]  (ATC  Glossary).  The  projection  on  the  earth’s  surface  of  the  path  of  an  aircraft,  the  direction  of  which 
path  at  any  point  is  usually  expressed  in  degrees  from  North  (True,  Magnetic,  or  Grid). 

TRACK  (ATC  Glossary).  The  actual  flight  path  of  an  aircraft  over  the  surface  of  the  earth.  (See  FLIGHT  PATH.)  (See 
ICAO  term  TRACK.) 

TRANSITION  (ATC  Glossary).  The  general  term  that  describes  the  change  from  one  phase  of  flight  or  flight  condition  to 
another;  e.g.,  transition  from  en  route  flight  to  the  approach  or  transition  from  instrument  flight  to  visual  flight.  A  published 
procedure  (SID  Transition)  used  to  connect  the  basic  SID  to  one  of  several  en  route  AIRWAYs/jet  routes,  or  a  published 
procedure  (STAR  Transition)  used  to  connect  one  of  several  en  route  AIRWAYs/jet  routes  to  the  basic  STAR.  (Refer  to 
SID/STAR  Charts.) 

TRANSITION  POINT  (ATC  Glossary).  A  point  at  an  adapted  number  of  miles  from  the  vertex  at  which  an  arrival  aircraft 
would  normally  commence  descent  from  its  en  route  altitude.  This  is  the  first  fix  adapted  on  the  arrival  speed  SEGMENTS. 

TRANSITIONAL  AIRSPACE  (ATC  Glossary).  That  portion  of  controlled  AIRSPACE  wherein  aircraft  change  from  one 
phase  of  flight  or  flight  condition  to  another. 
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UNPUBLISHED  ROUTE  (ATC  Glossary).  A  route  for  which  no  minimum  altitude  is  published  or  charted  for  pilot  use.  It 
may  include  a  direct  route  between  NAVAID's,  a  radial,  a  radar  vector,  or  a  final  approach  course  beyond  the  SEGMENTS  of 
an  instrument  approach  procedure.  (See  PUBLISHED  ROUTE.) 

VERTEX  (ATC  Glossary).  The  last  fix  adapted  on  the  arrival  speed  SEGMENTS.  Normally,  it  will  be  the  outer  marker  of 
the  runway  in  use.  However,  it  may  be  the  actual  threshold  or  other  suitable  common  point  on  the  approach  path  for  the 
particular  runway  configuration. 

VFR  MILITARY  TRAINING  ROUTES  (ATC  Glossary).  ROUTEs  used  by  the  Department  of  Defense  and  associated 
Reserve  and  Air  Guard  units  for  the  purpose  of  conducting  low-altitude  navigation  and  tactical  training  under  VFR  below 
10,000  feet  MSL  at  airspeeds  in  excess  of  250  knots  IAS. 

WARNING  AREA  (ATC  Glossary).  (See  SPECIAL  USE  AIRSPACE.) 

WAYPOINT  (ATC  Glossary).  A  predetermined  geographical  position  used  for  route/instrument  approach  definition,  or 
progress  reporting  purposes,  that  is  defined  relative  to  a  VORTAC  station  or  in  terms  of  latitude/longitude  coordinates. 
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Appendix  B:  TACC  Flight  Planning-related  Collaborative  Work  and  Flight 
Planning  Work  Analysis  and  Design  Effort  Analysis  Aids 


Flight  Planning  Work:  Abstraction  Hierarchy 


Obey 

Functional  Purpose: 

Achieve  Mission 

Maintain  Safety 

International 

Highest  Level  Goals 

Laws 
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Flight  Planning  Work  Flow:  Developing  a  ‘Notional  Flight  Plan 


Develop  Execution 
Right  Ran 
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Flight  Planning  Work  Flow:  Developing  an  ‘Execution  Flight  Plan 


3. 
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Life  Cycle  of  a  Mission:  ‘Notional  Plan  for  DIPS  Shop’ 


Flight  Manager  Controller  Maintenance 
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Select  Flight  Planning-related  TACC  Collaboration,  Coordination  Relationships 


Appendix  C:  DIP  Summary  Palette  Concept 


This  Appendix  documents  the  DIP  Summary  Palette  -  a  WCSS  'viewer'  concept  generated  and  briefed 
during  GAMAT  Phase  II.  This  concept  was  not  developed  further  during  the  Phase  II  effort.  To 
preserve  a  record  of  this  concept,  its  features,  and  the  rationale  underlying  it,  this  Appendix  is  provided. 

A  WCSS  ’Viewer’  for  Summary  DIP  Data 

In  the  course  of  the  GAMAT  Phase  II  effort  we  invested  considerable  time  in  examining  and  analyzing 
the  relationship  between  the  flight  planning  function  and  the  DIP  clearance  function.  The  feasibility  and 
availability  of  DIP  clearances  was  often  cited  as  a  primary  class  of  constraints  on  the  flight  planning 
process  and  the  ability  to  replan  flights  as  circumstances  demanded.  Through  our  knowledge  acquisition 
and  work-centered  analyses  we  determined  that: 

•  DIP  parameters  are  sufficiently  orderly  and  regular  as  to  be  represented  in  a  structured  way. 

•  The  criticality  of  DIP  status  was  sufficiently  high  to  recommend  prioritization  of  DIP  status 
visualization  as  a  component  of  any  TACC  collaborative  WCSS  suite. 

•  No  capability  for  rapid  summary  display  of  DIP  data  associated  with  a  mission  was  currently  in 
place. 

•  Certain  DIP-related  decision  elements  (e.g.,  planned  and  feasible  entry  and  exit  timeframes)  were 
not  directly  accessible  and  had  to  be  computed  or  interpreted  from  what  textual  data  could  be 
retrieved. 

•  To  the  extent  that  access  to  DIP  data  is  currently  feasible,  it  is  not  easily  available  across  the  entire 
TACC  team. 

•  Some  key  types  of  information  relevant  to  decision  making  with  regard  to  DIP  prospects  are  not 
accessible  at  all  beyond  the  bounds  of  the  DIP  shop  (e.g.,  the  number  of  blanket  clearances 
available). 

•  The  types  of  data  necessary  to  represent  DIP  status  were  accessible  and  tractable  enough  to  make  a 
DIP  'viewer'  a  feasible  prospect. 

•  A  widely-accessible  such  DIP  viewer  would  reduce  coordination  overhead  for  the  TACC  team  (e.g., 
allowing  flight  planners  or  execution  staff  to  directly  check  DIP  info  without  placing  a  call  to  the 
DIP  shop). 

•  Such  a  capability  would  help  mitigate  the  risks  of  DIP  factor  oversight  and  errors  during  time- 
critical  decision  making  processes  (e.g.,  during  the  execution  phase). 

•  A  WCSS  aid  providing  summary  DIP  status  data  associated  with  a  given  mission  would  be  a  useful 
work-centered  innovation. 
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As  a  result,  a  work-oriented  'viewer'  concept  was  generated  and  briefed  during  the  latter  stages  of  the 
GAMAT  Phase  II  effort.  In  the  sections  below  we  shall  review  the  features  of  this  WCSS  concept. 


General  Layout  of  the  DIP  Summary  Palette 

The  DIP  Summary  Palette  was  conceived  as  a  specialized  'viewer'  -  i.e.,  an  information  resource  which 
could  be  readily  invoked  to  provide  summary  data  for  a  given  topic  or  subject  (i.e.,  DIP  parameters) 
associated  with  a  given  mission.  The  concept  was  introduced  as  a  'palette'  (an  on-screen  window  with 
specific  structure).  This  palette  was  subdivided  into  two  basic  subareas:  (a)  a  header  area  for 
presentation  of  overview  information;  and  (b)  a  data  presentation  area  for  display  of  key  DIP  parameters 
in  a  structured  format.  This  general  layout  is  illustrated  in  Figure  D-l . 


Figure  D-l:  Overview  of  Dip  Summary  Palette  Layout 


In  the  following  sections  we  shall  provide  an  overview  of  the  interface  features  and  information  the  DIP 
Summary  Palette  was  designed  to  include. 


Information  Displayed  in  the  Header  Area 

The  Header  area  was  intended  to  contain  the  following  interface  elements: 

•  Pull-down  menus  for  general  on-screen  manipulation  and  configuration  control  in  accordance  with 
Windows  protocols. 
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•  A  text  window  displaying  the  identification  for  the  person  responsible  for  requesting  /  processing 
DIP  clearances  on  this  particular  mission.85 

•  A  checkbox  to  indicate  whether  or  not  the  given  mission  involved  Hazmat.86 

•  Title  headings  for  the  Data  Presentation  Area  elements  arrayed  below  the  Header  Area. 


These  are  the  generic  elements  of  information  judged  sufficiently  important  to  include  as  default  context 
for  all  instances  of  the  DIP  Summary  Palette. 


Information  Displayed  in  the  Data  Presentation  Area 

The  Data  Presentation  Area  is  the  'guts'  of  the  DIP  Summary  Palette.  This  is  the  area  of  the  WCSS 
widget  in  which  key  information  is  presented  in  a  manner  structured  to  fit  the  requirements  of  TACC 
decision  making  tasks  as  discerned  in  our  KA  and  work-centered  analyses.  The  Data  Presentation  Area 
is  organized  as  a  set  of  separate  but  closely  interrelated  subareas.  This  set  is  enumerated,  and  its 
members'  organization  illustrated,  in  Figure  D-2. 


99  This  feature  was  in  accordance  wiili  oui  longstanding  principle  of  cueing  TACC  uscis  as  to  who  is  wuikiug  a  paiticulai 
issue  or  subject. 

86  Inclusion  of  a  Hazmat  indicator  was  deemed  advisable  owing  to  the  fact  that  Hazmat  is  the  single  parameter  most 
commonly  cited  as  affecting  DIP  viability.  It  has  often  been  cited  as  a  factor  commonly  overlooked  or  unrecognized  by 
planning  and  execution  staff  when  making  time-critical  decisions. 
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Figure  D-2:  Subsidiary  Elements  of  the  Data  Presentation  Area 


The  set  of  display  subareas  within  the  Data  Presentation  Area  was  designed  to  provide  a  structured  set  of 

interface  elements  and  features  as  follows: 

•  The  main  component  of  the  Data  Presentation  area  is  a  central  tabular  array  of  information  elements 
arranged  so  as  to  offer  an  orderly  presentation  of  arrival  and  departure  endpoints,  nations  traversed, 
and  key  time  points  relating  to  DIP'S  associated  with  the  given  mission. 

•  This  tabular  array  constitutes  a  set  of  information  elements  organized  in  rows.  These  rows  are 
ordered  vertically  (top-to-bottom)  to  reflect  the  temporal  progress  of  the  flight. 

•  Because  DIP  clearances  are  addressed  nation-by-nation,  each  row  represents  the  DIP  data  pertaining 
to  one  nation  being  traversed  in  the  course  of  the  mission.87 

•  A  specific  information  element  specifying  the  Departure  Endpoint  for  the  mission's  route  is  given  in 
the  upper  left  (earliest  row  in  the  flight  sequence). 


87  It  is  presumed  that  there  will  be  conventions  for  treating  non-national  spaces  being  traversed  (e.g.,  international  airspace 
over  an  ocean)  in  the  same  manner  as  nations.  For  the  sake  of  this  introduction,  we  shall  refer  solely  to  'nations’. 
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•  A  specific  information  element  specifying  the  Arrival  Endpoint  for  the  mission's  route  is  given  in  the 
lower  right  (last  row  in  the  flight  sequence). 

•  Each  row  is  organized  to  reflect  temporal  sequence  from  left-to-right  (left  =  earlier;  right  =  later). 

•  In  the  center  of  each  row  is  an  element  displaying  the  country  being  traversed.  The  set  of  these 
nation  designations  is  termed  the  'Nations  List'. 

•  Each  of  the  nation  designations  is  color-coded  to  provide  visual  alerting  on  the  status  of  DIP 
clearances  for  that  particular  nation.88 

•  To  the  left  (i.e.,  'early  side')  of  each  row's  central  nation  designation  is  a  pair  of  data  elements 
pertaining  to  entry  times  (into  the  nation).  The  outboard  ('earlier')  one  displays  the  earliest  feasible 
entry  time,  and  the  inboard  ('later')  one  displays  the  predicted  entry  time. 

•  To  the  right  (i.e.,  'later  side')  of  each  row's  central  nation  designation  is  a  pair  of  data  elements 
pertaining  to  exit  times  (from  the  nation).  The  inboard  ('earlier')  one  displays  the  predicted  exit  time, 

•  ...  SO 

and  the  outboard  ('later')  one  displays  the  latest  feasible  exit  time. 

•  The  arrangement  of  the  elements  introduced  so  far  provides  an  orderly  protocol  for  reviewing  a 
mission's  DIP  parameters  in  accordance  with  the  sequence  of  the  flight. 

•  Reading  vertically  across  rows  gives  the  sequence  of  flight  across  nations  and  from  departure  to 
arrival  ports. 

•  Reading  horizontally  within  a  row  gives  the  logical  sequence  of  entry  and  exit  parameters  along  with 
the  associated  nation  and  DIP  alert  status. 

•  Each  of  the  nation  designations  is  color-coded  to  provide  visual  alerting  on  the  status  of  DIP 
clearances  for  that  particular  nation. 

•  Two  columns  to  the  right  of  each  row  provide  additional  data. 

•  These  columns  are  visually  segregated  from  the  otherwise-integral  row  presentations  in  accordance 
with  the  fact  they  provide  data  relevant  to  the  DIP  processing,  and  not  the  DIP  processed  (i.e.,  the 
work  and  not  the  work  results). 


88  Similar  to  other  of  our  WCSS  designs,  this  alert  function  employs  a  three-color  'stoplight'  metaphor.  A  green  color 
indicates  the  DIP  status  for  the  given  nation  is  'go'  /  'completed'.  A  yellow  color  indicates  that  DIP  clearance  for  the  given 
nation  is  'pending'.  A  red  color  indicates  a  'no  go'  condition.  This  scheme  provides  for  (e.g.)  automated  cueing  on  which  of 
potentially  several  nations  represent  a  DIP  problem. 

9  The  arrangement  of  these  entry  and  exit  time  designations  to  either  side  of  the  central  nation  designation  is  quite  deliberate. 
They  are  horizontally  segregated  by  the  nation  designation  to  allow  rapid  disci imination  between  cntiy  and  exit  data.  They 
are  horizontally  ordered  to  allow  coherent  assessment  of  the  four  timepoints  as  they  should  be  ordered  in  a  feasible  traversal 
of  a  nation.  If  the  data  displayed  does  not  reflect  this  presumptive  feasible  ordering  (e.g.,  if  predicted  entry  is  earlier  than 
earliest  feasible  entry  or  predicted  exit  is  later  than  latest  feasible  exit)  the  row  should  be  flagged  red  to  alert  the  user  of  a 
problem. 
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•  The  inboard  column  displays  the  conventionally-delineated  lead  time  left  for  processing  a  DIP 
request  for  the  country  designated  in  the  associated  row. 

•  The  outboard  column  displays  two  pieces  of  data  relating  to  blanket  clearances  for  the  country 
designated  in  the  associated  row. 

•  The  first  piece  of  blanket  clearance  data  is  whether  or  not  there  are  blanket  clearances  available  for 
the  given  nation  at  all.  This  is  cued  on  a  'yes  /  no'  basis. 


The  second  piece  of  blanket  clearance  data  (only  provided  for  nations  offering  blanket  clearances  -  i.e., 
when  the  first  datum  is  a  ’yes')  is  the  number  of  such  blanket  clearances  remaining  available  at  the 
present  time. 


Discussion 

The  DIP  Summary  Palette  was  designed  to  provide  the  same  sort  of  one-stop  'viewer'  capability  the 
HISA  Port  Viewer  represented.  The  layout  of  the  rows  and  their  subsidiary  elements  was  intended  to 
provide  the  most  critical  elements  of  DIP  information  in  a  stmctured  fashion.  During  the  FY03  work,  it 
was  noteworthy  to  learn  that  there  is  no  structured  summary  of  DIP  data  for  a  given  mission.  Such  data 
is  available,  to  be  sure,  but  it  must  be  laboriously  extracted  from  (e.g.)  the  generally  unstructured  set  of 
text  documentation  stored  in  the  LogBook  application.  Although  this  relatively  unstmctured  and  text¬ 
intensive  approach  may  suffice  for  the  DIP  planners  who  deal  with  it  regularly,  it  is  a  cumbersome  type 
of  information  support  for  other  TACC  team  members  who  may  need  to  check  DIP  information  on  a 
given  mission.  This  cumbersome  character  is  particularly  detrimental  for  those  who  must  quickly 
evaluate  DIP  status  in  support  of  time-critical  decision  processes  (e.g.,  re-planning  during  the  execution 
phase). 

The  organization  of  the  row-wise  data  presentation  in  the  DIP  Summary  Palette  derives  from  the  WCD 
principle  that  visualization  should  reflect  the  form  of  the  subject  matter  as  it  is  addressed  in  the  course  of 
the  work  process.  In  this  case,  the  organizing  principle  is  obvious.  As  documentary  products  being 
negotiated,  DIP  clearances  are  assigned  and  processed  nation-by-nation.  Relevant  external  points  of 
contact,  specific  requirements,  and  procedures  are  similarly  differentiable  on  the  basis  of  national 
entities  involved.  Finally,  the  referential  intersection  of  DIP  clearances  and  flight  progress  is  a  sequence 
punctuated  by  the  exit  from  one  national  space  and  entry  into  a  subsequent  one. 

The  DIP  Summary  Palette  was  designed  to  incorporate  work-centered  features  analogous  to  those 
provided  in  our  earlier  WCSS  concepts  and  prototypes.  One  such  feature  is  summary  alert  presentation 
and  coding  to  allow  TACC  team  members  to  rapidly  check  the  status  of  DIP  clearances  for  a  given 
nation.  One  striking  feature  of  current  TACC  operations  is  the  ironic  combination  of  high  mission 
criticality  and  low  degree  of  team-wide  situation  awareness  associated  with  DIP  clearances. 
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The  lead  time  and  blanket  clearance  data  elements  were  incorporated  into  the  DIP  Summary  Palette 
concept  to  meet  the  WCD  requirement  that  a  given  WCSS  interface  product  should  provide  the  user(s) 
with  the  full  range  of  information  necessary  to  not  only  evaluate  the  state  of  work  being  processed,  but 
also  the  factors  affecting  the  course  of  that  work  process.  DIP  application  lead  time  is  a  factor  which 
can  'make  or  break'  the  prospects  for  modifying  a  flight  plan  late  in  the  planning  phase  or  anytime 
during  the  execution  phase.  As  a  result,  access  to  lead  time  requirements  could  facilitate  evaluation  of 
options  for  a  variety  of  people  outside  the  DIP  shop.  For  example,  providing  TACC  team  members 
outside  the  DIP  shop  with  a  cue  on  the  lead  time  requirements  would  enable  them  to  identify  'no  way' 
situations  without  wasting  time  on  personal  communication  with  a  DIP  specialist  and  facilitate  their 
moving  on  to  focus  on  feasible  solution  paths.  Similarly,  cueing  non-DIP  team  members  on  blanket 
clearance  availability  would  provide  valuable  clues  as  to  whether  there's  a  backup  option  when 
confronted  with  a  priority  requirement  for  generating  or  modifying  DIP  permissions  on  short  notice. 
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